[要約] RFC 2795は、無限の猿プロトコルスイート（IMPS）に関する規格であり、分散コンピューティングのためのプロトコルとアルゴリズムを提供します。その目的は、複数のコンピュータを使用してタスクを効率的に実行するための方法を提供することです。
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.
Copyright（c）The Internet Society（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
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.
Infinite Monkey Protocol Suite（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ネットワーク内で通信する4つの主要なエンティティがあります。サルのグループは、物理的にゾーンオペレーション組織（ZOOS）に位置しています。動物園は、サルとその機器を維持し、サルのタイプライターから転写産物を取得し、転写産物を評価する他のエンティティと相互作用します。
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.
SIMIAN（半統合された猿の介入擬人化ノード）は、サルに物理的に取り付けられているデバイスです。猿とその動物園の間の通信インターフェースを提供します。事実上、サルの翻訳者です。人間の言語フレーズを使用して動物園にステータスレポートとリソースリクエストを送信し、サルに代わって動物園のリクエストに応答します。
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.
Simianは、クロスハビタットの慣用メッセージプロトコル（Chimp）を使用して動物園と通信します。動物園は、Ecosystem Resources（Keeper）に知識豊富で効率的なエミュレーションプロトコルを使用して、Simianと対話します。
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.
動物園では、非デジタルタイプライターが使用されている場合は、サルのタイプされたテキストを電子形式に変換する責任があるSimianからタイプライターの転写産物を取得します。その後、動物園は、転写産物の内容を確認する1つ以上のエンティティに転写産物を転写することができます。IMPSは、そのようなレビュアープロトコルの2つを定義しますが、他のレビュアープロトコルを追加できます。
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.
シェークスピア作品や、すでに公開されている他の古典文学については、動物園はトランスクリプトを吟遊詩人（参照文書の大きな付属書）に転写します。バードは、転写産物が付属書の1つ以上のドキュメントと一致するかどうかを判断します。動物園は、新古典的な転写産物（IAMB-PENT）を評価するためのANNEX Inter-Annexメッセージブロードキャストプロトコルを使用して、トランスクリプトをバードに送信します。トランスクリプトは、（a）元の紙媒体の代わりに電子メディアで転送されるため、（b）「classical」という言葉は文字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の概念の図を以下に示します。中間レベルのマネージャー、マーケティング担当者、リベラルアーツ専攻などの非技術的な読者は、次の2つのセクションをスキップすることをお勧めします。この文書の残りの部分は、上級管理職がすでに読み物を停止していると想定しています。
-+-+-+-+-+- 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 |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
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.
サイズフィールドは、無限のタグエンコーディングを使用してパケット全体のサイズを記録します。
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.
各SIMIANには、IMP内の一意の識別子が必要です。このセクションでは、無限のしきい値アカウンティングガジェット（I-TAG）と呼ばれるIMPS識別子の設計上の考慮事項について説明します。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.
各SIMIANを一意に識別するには、無限の数の識別子を表すことができるシステムが必要です。すべての整数のセットは、コンパクトな表現として使用できます。ただし、既存のすべてのプロトコルは、整数に使用される最大バイト数を指定することにより、利用可能な整数の数を本質的に制限します。このアプローチは、管理する無限の数のサルを備えた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）サブ原子サルおよび/または複数の宇宙を利用する可能性のあるIMPの実装を不必要に除外します。（b）この宇宙にはいくつの原子があるかについては、コンセンサスはありません。（c）数は非常に大きいが、それでも無限に哀れなほど不足している。Impsを完全に実装するエンティティは、おそらく無限の数値を処理するのに非常に優れている可能性があるため、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.
ネットストリング、つまり、独自のサイズをコードする文字列が考慮されました。ただし、ネットストリングは標準として受け入れられておらず、無限にスケーリングしていません。[9]で述べたように、「[999999999バイトは悪い]。よく置きます。
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タグのアイデアにすでに感情的に結び付けられていました。ただし、サルがこの特定のセクションを入力し、批評家に提出された場合、おそらくホイールの再発明を示すパン拒否コードを受け取る可能性があることに注意する必要があります。
Since there is no acceptable representation for I-TAGs available, one is defined below.
利用可能なIタグの許容可能な表現はないため、以下に定義されています。
An I-TAG is divided into three sections:
Iタグは3つのセクションに分かれています。
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
| 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を表すために使用されるバイトの数を指定します。メタサイズは、サイズを表すために使用されるビット数の上限を指定します。
META-SIZE is an arbitrary length sequence of N '1' bits terminated by a '0' bit, i.e. it has the form:
メタサイズは、 '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（任意のnの場合）未満の任意の数値xの場合、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].
Iタグ処理を実装するには、驚くべきエレガントな小さなC関数が書かれていますが、このマージンに含めるにはあまりにも多くのコードがあります[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.
以下は、動物園がSimianと通信するために使用する生態系リソース（キーパー）の知識豊富で効率的なエミュレーションプロトコルの説明です。キーパーの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:
キーパーはコネクションレスプロトコルです。動物園は、単一のIMPSパケットを使用してSimianにリクエストを送信します。Simianは、別のImpsパケットを使用して動物園に応答を送り返します。パケットのデータ部分は次の形式です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
動物園がキーパーリクエストを送信する場合、Simianは元のリクエストと同じメッセージ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 | 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.
以下は、キーパー内のリクエストと応答コードの要件です。
1. A SIMIAN must respond to a STATUS request with an ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, or NORESPONSE code.
1. Simianは、生きている、死んでいる、眠り、消えてしまった、気を散らされた、またはNoresponseコードでステータスリクエストに応答する必要があります。
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. Simianは、生きているコードまたは死んだコードを使用して、ハートビートリクエストに応答する必要があります。Simianの実装者は、超越的な瞑想やヨガを練習する非常にリラックスしたサルの鼓動をチェックするときは注意する必要があります。
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. Simianは、Noresponse、Alive、Dead、またはGoking Codeを使用したSTOPリクエストに応答する必要があります。Simianが猿を停止する方法は、実装固有です。ただし、Simianは、猿の生きている地位を保存して、動物園が当局または動物の権利団体によって閉鎖されるのを防ぐべきです。猿が存在しますが、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. Simianは、特に期限がある場合は、受け入れコードを使用してタイプまたはより高速なリクエストに応答する必要があります。他の唯一の許可された応答は、拒否、眠り、消え、ノルスペン、または死んでいることです。このプロトコルは、SIMIANがREFUSで応答した場合にどのようなアクションを実行すべきかを定義しませんが、BRIBE_BANANAコマンドは将来のバージョンに追加される可能性があります。
5. A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD.
5. SIMIANは、受け入れ、拒否、なくなった、ノルスペン、または死亡したウェイクアップリクエストに応答する必要があります。
6. A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.
6. Simianは、トランスクリプトを動物園に送信するためにチンパンジーセッションを確立することにより、トランスクリプトリクエストに応答する必要があります。
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という名前の猿と対話しなければならないと仮定します。キーパーを使用して、SandiegoはBoboのSimian（Bobosim）とインターフェイスします。ボボが自己認識と独立性を進化させ始めた場合、次の交換が行われる可能性があります。
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.
ボボが維持されておらず、前夜遅くにそのタイプライターで働いていた場合、次の交換は早朝に行われる可能性があります。
SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> HEARTBEAT BoBoSIM> DEAD SanDiego> TRANSCRIPT
サンディエゴ>ウェイクアップボボシム>応答なし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.
以下は、Simianが動物園と通信するために使用するクロスハビタットの慣用メッセージプロトコル（Chimp）の説明です。Chimpの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は、接続指向のプロトコルです。SIMIAN（「クライアント」）は、一連のリクエストを動物園（「サーバー」）に送信します。これは、返信をSimianに送り返します。
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は特定のリソースを要求しています。資源は、食物、水、薬、獣医、または技術者です。Simianは、猿の行動と環境を解釈することにより、食物や水を要求します。そのフード料理。猿の健康が何らかの形で減少していることを観察した場合、薬または獣医を要求します。手根管症候群または尻の痛み。Simianが健康をどのように決定するかは、実装固有です。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>
クリーン<アイテム>
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.
Simianは、動物園がアイテムをきれいにする必要があることを要求しています。アイテムは、椅子、テーブル、またはサルです。動物園がアイテムをクリーニングする方法は、実装固有です。このコマンドは、無限の数のサルが無限の数のタイプライターに座っている場合、臭いは耐えられないと理論化されているため、プロトコルで特定されています[12]。この理論が真であることが証明されている場合、クリーンはプロトコルスイート全体で最も重要なコマンドになる可能性があります。
NOTIFY <status>
<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.
Simianは、猿の地位を動物園に通知します。ステータスは、キーパープロトコルで定義されている任意のステータス、つまり、眠り、消え、気を散らし、noresponse、生きている、または死んでいる場合があります。
TRANSCRIPT <size>
トランスクリプト<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.
Simianは、サルからの新しい転写産物の動物園に通知します。トランスクリプト内の文字の数は、サイズパラメーターで指定されています。
BYE
さよなら
The SIMIAN is terminating the connection.
Simianは接続を終了しています。
HELO <free text>
helo <free text>
Upon initial connection, the ZOO must send a HELO reply.
最初の接続時に、動物園はHELOの返信を送信する必要があります。
ACCEPT
受け入れる
The ZOO will fulfill the SIMIAN's request.
動物園はSimianの要求を満たします。
DELAY
遅れ
The ZOO will fulfill the SIMIAN's request at a later time.
動物園は、後でSimianの要求を満たします。
REFUSE
拒否する
The ZOO refuses to fulfill the SIMIAN's request.
動物園は、Simianの要求を満たすことを拒否します。
RECEIVED
受け取った
The ZOO has received the full text of a transcript that has been submitted by the SIMIAN.
動物園は、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.
Bobosimという名前のSimianインターフェイスと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> REFUSE BoBoSIM> NOTIFY NORESPONSE SanDiego> ACCEPT BoBoSIM> NOTIFY DEAD SanDiego> ACCEPT BoBoSIM> REPLACE MONKEY SanDiego> ACCEPT
Sandiego> Helo Chimpバージョン1.0 4/1/2000 Bobosim>交換紙Sandiego> Bobosim>を受け入れる> Transcript 87 Sandiego> Bobosim> Xvkxvn私はBinky Xfnkを嫌い、空腹と病気のsbnf bobosim>とても悲しいsdnfkodgv。、n。help meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee cvn l Sandiego> Bobosim> send Food Sandiego> Bobosimを受け入れる>薬を受け入れる>薬> Delied Bobosim> veterinarian Sandiego> Reduse Bobosim> veterinarian sandiego>拒否Bobosim> Noresponse 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）を評価するためのAnnex間メッセージブロードキャストプロトコルの説明です。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>
<トランスクリプト名>を受け取ります
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>
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>
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>
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.
動物園が受け取ったコマンドを使用して今後の転写産物を指定する場合、吟遊詩人はプリシーで応答する必要があります。A2、A3、A4、およびA5には音節を強調する必要があります。U3、U4、およびU5にアクセントを付けてはなりません。
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>
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.
吟遊詩人がその付属書に転写産物を見つけた場合、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).
これは、動物園（Sandiego）が吟遊詩人（William）に転写産物を送信するサンプルIAMB-PENTセッションです。
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
ウィリアム>今、yonder窓からどんな光が壊れますか？Sandiego>トランスクリプトSandiego.17 William> Prithee Thy Monkeyの知恵が注がれます！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の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>
補足<テキスト>
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>
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.
動物園がつながりを確立するとき、批評家はため息とオプションのin辱で応答しなければなりません。
IMPRESS_ME
私を感動させる
A CRITIC must respond with an IMPRESS_ME once a ZOO has made a TRANSCRIPT request.
批評家は、動物園がトランスクリプトリクエストを行ったら、Impress_meで応答する必要があります。
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
dont_call_us_we'll_call_you
The CRITIC makes this statement before terminating the connection.
批評家は、接続を終了する前にこの声明を発表します。
GRUDGING_ACCEPTANCE
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ではサポートされていません。Infinite Monkey Protocol Suite（WIMPS）のワーキンググループは、拒否が利用可能になったときに批評家がこの応答を使用する可能性は非常に低いことに同意しました。批評家がどのように機能するかを完全に理解していない実装者への説明としてのみ含まれています。やがて、批評家が進化する可能性があります（猿とほぼ同じ方法で）。そのような時が来た場合、Wimpsは後のバージョンの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."
-------------------------------------------------------------------
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>賛辞の宝石のようなもので、あなたはいつも正しいです。Sandiego> Transcript romeoandjuliet.bobo.763 251 nobrainer> Impress_me Sandiego>どちらも尊厳のある2つの世帯、Sandiego>公正なヴェローナで、シーンを築きます。市民の手は汚れています。Sandiego>これら2つの敵の致命的な腰からSandiego>スタークロスの恋人のペアが命を奪います。nobrainer>拒否2（ "これは決して売れないでしょう。"）sandiego>ありがとうnobrainer> dont_call_us_we'll_call_you
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.
動物の人道的な扱いの原則に従って、IMPの設計は、批評家がSimianに直接連絡してその感情を傷つけることを特に禁止しています。基本的な互換性とデザインの欠陥のために、吟遊詩人や批評家も分離されています。
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のセキュリティ上の考慮事項は、元のインターネットプロトコルのセキュリティに関するものと似ています。具体的には、Impsは過去の過ちから学ぶことを拒否し、目を打つことなく同じエラーをいっぱいに繰り返します。信頼されていないエンティティが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 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.
動物園は、世界中の擬似シミアンによる搾取のために開かれたままになる可能性があります。サードパーティは、動物園とSimianの間の通信を中断する可能性があり、パケットごとにメッセージIDを1枚増加させることにより、動物園とSimianの間の通信を中断することができます。さらに凶悪に、パーティーは各SIMIANに単一の停止要求を送信することにより、キーパープロトコルを悪用する可能性があり、動物園全体で大規模なサービス拒否を引き起こす可能性があります。パーティーはまた、チンパンジーの要求を投げかけたり、死んだステータスなどの誤った情報を送信したりする可能性があります。これにより、動物園がまだ適切に機能している猿を交換しようとする可能性があります。
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.
さらに、動物園がSimianの要求（特に食物、水、獣医用の要求）を繰り返し拒否した場合、動物園はその特定のSimianに関して不注意に独自の奉仕を引き起こす可能性があります。ただし、キーパーとチンパンジーの両方により、動物園はこの状態をNoresponseまたはDeadステータスコードを介してタイムリーに検出することができます。
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.
すべての吟遊詩人は、克服できない経済的問題と優先順位付けが低いため、本質的に不安定です。これにより、確実に機能することができません。吟遊詩人の実装がこれらの障害を克服するまれな場合、それは15分間しか成功しておらず、その後すぐに不安定になるように戻ります[14]。批評家は、適切なパンの反応で吟遊詩人の成功を大幅に減らすことができるため、これが吟遊詩人や批評家を常に互いに別々に保つべきもう1つの理由です。
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?
批評家のほとんどの実施を気にする人はほとんどなく、批評家自身が本質的に不安定であると予想されます。したがって、セキュリティは批評家にとって優先事項ではありません。批評家は、あまりにも多くのSIMIANが同時に転写産物を提出した場合、サービス拒否攻撃の犠牲者になる可能性があります。さらに、1人のSimianは、別のSimianをスプーフィングすることにより、非侵害的な作業を提出する場合があります（これは盗作問題と呼ばれます）。批評家の反応もスプーフィングすることができますが、PANバージョン1でサポートされている唯一の応答は拒否されるため、これはほとんど結果ではありません。Grudging_acceptanceの応答が許可されている場合は、将来のバージョンで注意する必要があります。最後に、転写産物が伝送で失われる可能性があり、パンは動物園がこれが起こったかどうかを判断するメカニズムを提供しません。IMPの将来のバージョンは、この基本的なデザインの問題に答えるのに適している可能性があります。革新的な作業が送信で失われた場合、批評家はまだそれをパンできますか？
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].
近年発見されたパケットレベルの脆弱性の数に基づいて、不正なパディングまたは予約ビットで不正行為のIMPを処理すると、いくつかの実装が非常に劣っているということは、いくつかの実装が非常に貧弱に動作するということは当然の結論です[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].
最後に、無限の時間の過程で、サルが独自のSimianインターフェイスを制御し、誤った要求を送信する方法、または独自のトランスクリプトを作成して提出する方法を発生させて発見する可能性があるという事実に関して、セキュリティ上の考慮事項は行われません。これがすでに起こっている可能性があるという兆候があります[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.
著者は、この文書のサイズを3倍にした技術的なコメント、シェークスピアの文法に関する講義についてのKean KaufmannとAmanda Vizedom、宇宙全体の性質を明確にするためのRohn Blake、Accents、Number 16、および16、およびWilliam Shakespeareの講義について、Andre Frechに感謝したいと考えています。黄色の色。
[1] The Famous Brett Watson, "The Mathematics of Monkeys and Shakespeare." http://www.nutters.org/monkeys.html
[1] 有名なブレット・ワトソン、「サルとシェークスピアの数学」。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] 数学博士。「シェークスピアを入力するサル：インフィニティ理論。」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] K. Clark、Stark Mill Brewery、マンチェスター、ニューハンプシャー州、米国。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年からこの文書の日付の間に公開されたTVガイドの問題で参照を見つけることができませんでした。
[5] "Dough Re Mi," The Brady Bunch. Original air date January 14, 1972.
[5] 「生地re mi」、ブレイディの束。元の放送日1972年1月14日。
[6] Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.
[6] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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。and A. Malis、「Multiprotocol Interconnect over Frame Relay」、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] Internet-Draft、Bernstein-Netstrings-06（期限切れの作業が進行中）。D.J.バーンスタイン。この参照を含めることは、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 and Beyond」、RFC 2550、1999年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] 「皮肉を認識したり、読んだときにだまされないようにしないでください。」フェイ・ハルパーン。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アドバイザリーCA-98-13。証明書1998年12月。http：//www.cert.org/advisories/
[16] CERT Advisory CA-97.28. CERT. December 1997. http://www.cert.org/advisories/
[16] CERTアドバイザリーCA-97.28。証明書1997年12月。http：//www.cert.org/advisories/
[17] CERT Advisory CA-96.26. CERT. December 1996. http://www.cert.org/advisories/
[17] CERTアドバイザリーCA-96.26。証明書1996年12月。http：//www.cert.org/advisories/
[18] All issues of TV Guide published between 1956 and the date of this document.
[18] 1956年からこの文書の日付の間に公開されたTVガイドのすべての問題。
SteQven M. Christey EMail: steqve@shore.net
Steqven M. Christeyメール：steqve@shore.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。