Network Working Group S. Christey
Request for Comments: 2795 MonkeySeeDoo, Inc.
Category: Informational 1 April 2000
The Infinite Monkey Protocol Suite (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
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ネットワーク内で通信4つの主なエンティティがあります。サルのグループは、物理的にゾーンの動作組織（動物園）に位置しています。動物園では、サルや自社の機器を維持するサルのタイプライターからの転写産物を取得し、転写産物を評価する他のエンティティと対話します。
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（半統合、猿-のインタフェース擬人化ノード）は、物理的に、サルに取り付けられている装置です。これは、猿とそのZOOとの間の通信インタフェースを提供します。これは、効果的に猿のための翻訳者です。これは、人間の言語の句を使用してZOOにステータスレポートやリソース要求を送信し、サルの代わりにZOOの要求に応答します。
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はZOOと通信するためにクロス生息地慣用的メッセージプロトコル（CHIMP）を使用します。 ZOOは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.
ZOOは、非デジタルタイプライターを使用している場合は、電子形式にサルの入力したテキストを変換するための責任があるSIMIANから、タイプライターの転写産物を得ます。 ZOOは、トランスクリプトの内容を見直す一の以上のエンティティへの転写産物を転送することができます。他は加えることができるが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.
シェークスピアの作品だけでなく、すでに公開されている任意の他の古典文学のために、ZOOはBARD（参考書類のビッグ附属書）にトランスクリプトを転送します。転写物はその別館内の1つの以上の文書に一致した場合BARDが決定します。 ZOOは、新古典主義の転写産物（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.
新しい、潜在的に革新的な作品で、ZOOはCRITIC（コレクティブレビューの革新的なトランスクリプトの統合センター）に写しを提出します。トランスクリプトが公開されるのに十分革新的である場合には評論家を決定します。 ZOOはCRITICと通信するために新規性の評価のためのプロトコル（PAN）を使用します。 CRITICにトランスクリプトを送信するために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).
SourceとDestinationが通信している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は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.
一意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）には、不サブアトミックサル及び/又は複数のユニバースを利用することができるIMPSの実装を排除します。 （b）は、この宇宙に存在するどのように多くの原子のようなコンセンサスがありません。数が非常に大きいながら（C）、それはまだ無限の哀れ下回ります。完全IMPSを実装する任意のエンティティは、おそらく無限の数字を扱うのは非常に、非常に良いですので、IMPSは、それらを表現できるようにする必要があります。
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.
Netstrings、自分のサイズをコードすなわち文字列は、考慮されました。しかし、netstringsは標準として受け入れられていない、と彼らは無限に拡張できません。 [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問題を解決し、無限にスケールをしていますが、8よりも大きい要因によってそのASCII表現廃棄物のメモリが、これはサルの無限の数をサポートするのに十分なリソースを持っている環境では重要思えないかもしれませんが、それはのために洗練されていません猿の識別のため。これは、（少なくともLISP、Perlの、およびJavaの組み合わせで書かれた著者の実装に基づいて）進数に、そのような表現に変換するためにもCPU集約的です。アルゴリズムが複雑であり、間違った実装につながる可能性があります。適切に含まれるように遅すぎた、とすでに感情とにかくI-TAGのアイデアに取り付けたまで最後に、本書の著者は、一種のRFCを忘れてしまいました。猿は、この特定のセクションを入力した、それは評論家に提出された場合、それはおそらく、車輪の再発明を意味するPANの拒否コードを受け取ることになることに留意すべきです。
Since there is no acceptable representation for I-TAGs available, one is defined below.
利用可能なI-タグの受け入れ可能な表現が存在しないので、一方は以下に定義されます。
An I-TAG is divided into three sections:
I-TAGは、次の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.
SIZEは、任意の整数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.
SIZEは、次に、最上位ビットから最下位ビットまで順序付けられたN個のビットを用いて符号化されます。
Finally, the ID is encoded using SIZE bytes.
最後に、IDはSIZEバイトを使用して符号化されます。
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.
この表現は、不格好ながら、メモリを効率的に利用し、無限にスケーラブルです。 （任意の整数Nにおいて）2^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].
顕著な、上品少し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.
以下は、動物園SIMIANと通信するために使用するエコシステムリソースの知識と効率的なエミュレーションプロトコル（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はコネクションレスプロトコルです。 ZOOは、単一のIMPSのパケットを使用してSIMIANに要求を送信します。 SIMIANは別のIMPSパケットバックZOOへの応答を送信します。パケットのデータ部分は、次の形式のものです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
バージョン = KEEPERのバージョン（本書では、バージョンは1です）
Type = the type of message being sent. '0' is a request; '1' is a response
タイプ = 送信されるメッセージの種類。「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.
ZOO KEEPERは、要求を送信すると、SIMIANは、元の要求と同じメッセージIDを使用していますKEEPER応答を送信する必要があります。
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.
以下は、KEEPER内の要求と応答コードのための要件です。
1. A SIMIAN must respond to a STATUS request with an ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, or NORESPONSE code.
1. SIMIANは、ALIVE DEAD、ASLEEP、GONE、DISTRACTED、または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はALIVEまたはDEADコードでハートビート要求に応答しなければなりません。超越瞑想やヨガの練習は非常にリラックスしたサルのハートビートをチェックするとき、彼らはまだ生きている場合でも、DEAD表示される場合がありますよう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、またはGONEコードでSTOP要求に応答しなければなりません。どのようにSIMIANは、サルは実装固有で停止します。しかし、SIMIANは当局や動物保護団体によってシャットダウンされることからZOOを保護するためにサルのALIVEの状態を維持する必要があります。猿が存在するが、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は期限がある場合は特に、ACCEPTコードをTYPEまたはFASTER要求に応答する必要があります。唯一の他の許可応答がREFUSE、ASLEEP、GONE、NORESPONSE、またはDEADあります。このプロトコルは、SIMIANはREFUSEで応答した場合BRIBE_BANANAコマンドは、将来のバージョンで追加されるかもしれないが行動が取られるべきかを定義しません。
5. A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD.
5. SIMIANはACCEPT、REFUSE、GONE、NORESPONSE、またはDEADとウェイクアップ要求に応答しなければなりません。
6. A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.
6. SIMIANはZOOにトランスクリプトを送信するためにCHIMPセッションを確立することによりTRANSCRIPT要求に応答しなければなりません。
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.
ZOO（サンディエゴ）がボボという名前の猿と相互作用しなければならないものとします。 KEEPERを使用して、サンディエゴには、ボボのSIMIAN（BoBoSIM）とのインタフェースです。ボボは自己認識と独立性を進化させ始めた場合、次の交換が行わがかかる場合があります。
SanDiego> STATUS BoBoSIM> DISTRACTED SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> GONE
サンディエゴ > ステータスBoBoSIM気を取らサンディエゴ > BoBoSIMはお断りサンディエゴ > TYPEタイプTYPE BoBoSIMはサンディエゴ > 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
サンディエゴ > ウェイクアップBoBoSIM NORESPONSEサンディエゴ > ウェイクアップBoBoSIM NORESPONSEサンディエゴ > ウェイクアップBoBoSIM NORESPONSEサンディエゴ > ハートビートBoBoSIM > デッドサンディエゴ > トランスクリプト
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.
以下サル動物園と通信するために使用するクロス生息地慣用的メッセージプロトコル（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に回答を送信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は特定のリソースを要求しています。資源は食料、水、医薬品、獣医師、または技術者かもしれません。 SIMIANは、例えば、サルの行動や環境を解釈することによって食べ物や水の要求を行いますその食品の一品。それはサルの健康状態は、例えば、どのような方法で減少していることを観察した場合には、医学または獣医師を要求します手根管症候群または痛み臀部。どのようにSIMIANは、健康は実装固有であると判断します。 SIMIAN自体が故障してもよい場合には、技術者に要求することができます。
REPLACE <item>
REPLACE <項目>
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.
ZOOは活動を入力する時に猿によって使用されているアイテムを交換する必要があります。置換されるアイテムタイプライター、紙、リボン、椅子、テーブル、またはサルであってもよいです。
CLEAN <item>
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はZOOがアイテムをきれいにしなければならないことを要求しています。アイテムは、椅子、テーブル、またはサルであってもよいです。どのようZOOがアイテムをきれいにすることは実装固有です。それが理論化されているため、このコマンドは、サルの無限の数がタイプライターの数が無限に座った場合、臭いは耐え難いだろうとプロトコルで識別された[12]。この理論が真証明されている場合は、CLEANは、全体のプロトコルスイートの中で最も重要なコマンドになることがあります。
NOTIFY <status>
NOTIFY <状態>
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は猿のステータスのZOOを通知します。 KEEPERプロトコル、すなわちASLEEP、GONE、伸延、NORESPONSE、ALIVE、またはDEADで定義されるように状態がいかなる状態であってもよいです。
TRANSCRIPT <size>
TRANSCRIPT <サイズ>
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は猿から新しい転写産物のZOOを通知します。転写産物の文字数はサイズパラメータに指定されています。
BYE
BYE
The SIMIAN is terminating the connection.
SIMIANは、接続を終了しています。
HELO <free text>
HELO <フリーテキスト>
Upon initial connection, the ZOO must send a HELO reply.
最初の接続時には、ZOOはHELO応答を送信する必要があります。
ACCEPT
ACCEPT
The ZOO will fulfill the SIMIAN's request.
ZOOはSIMIANの要求を満たすだろう。
DELAY
DELAY
The ZOO will fulfill the SIMIAN's request at a later time.
ZOOは後でSIMIANの要求を満たすだろう。
REFUSE
REFUSE
The ZOO refuses to fulfill the SIMIAN's request.
ZOOはSIMIANの要求を満たすことを拒否します。
RECEIVED
RECEIVED
The ZOO has received the full text of a transcript that has been submitted by the SIMIAN.
ZOOは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インターフェース、およびサンディエゴという名前の動物園でサルボボを想定。 BoBoSIMクライアントはサンディエゴのサーバへの接続を確立したら、次のセッションが行わがかかる場合があります。
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
サンディエゴ> Helouチャイムバージョン1.0 2000年4月1日BoBoSIM> PAPERサンディエゴをREPLACE> ACCEPT BoBoSIM転写物87サンディエゴ>私は空腹や病気sbNf BoBoSIM SA SA悲しいsDNfkodgvを感じ、Binky xFnk嫌いBoBoSIMのxvkxvnをACCEPT。、N. HELP MEEEEEEEEE cv.Cvnリットルのサンディエゴ>受信BoBoSIM>送信FOODサンディエゴ> BoBoSIMをACCEPT>送信医学サンディエゴ> DELAY BoBoSIM>送る獣医サンディエゴ> REFUSE BoBoSIM>獣医を送ります
SanDiego> REFUSE BoBoSIM> NOTIFY NORESPONSE SanDiego> ACCEPT BoBoSIM> NOTIFY DEAD SanDiego> ACCEPT BoBoSIM> REPLACE MONKEY SanDiego> ACCEPT
サンディエゴ>> BoBoSIMがNORESPONSEサンディエゴに通知REFUSE BoBoSIMデッドサンディエゴに通知ACCEPT> BoBoSIMをACCEPT> MonkeymanサンディエゴをREPLACE> ACCEPT
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.
ZOOはBARDに転写産物を送信するために使用する新古典主義の転写産物（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はコネクション指向のプロトコルです。 ZOO（「クライアント」）は、転写産物を評価し、転写物は、古典的な仕事またはその部分のすべてに一致する場合ZOOを通知BARD（「サーバー」）、に転写フレーズを送信します。
RECEIVETH <transcript name>
RECEIVETH <トランスクリプト名>
The ZOO notifies the BARD of a new transcript to be evaluated. The name of the transcript is provided.
ZOOは、新しい転写物のBARDが評価されるように通知します。転写物の名前が提供されています。
ANON <size>
ANON <サイズ>
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.
ZOOは、指定されたサイズの転写物がすぐに提供されるべきであるBARDに通知します。トランスクリプトのテキストは、次に送信されます。
ABORTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
Abertt <AA> <行為> <行為> <4> <a 4> <兄> <兄>
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.
ZOOは、接続を閉じるうとしているBARDに通知します。 ZOOは終了メッセージを指定する必要があります。 A2、A3、A4、A5とは音節をアクセントにする必要があります。 U3、U4、U5とはアクセントしてはいけません。
HARK <U1> <A2> <U3> <A3> <U4> <A4> <U5> <A5>
燃焼<1> <AA> <行為> <行為> <4> <a 4> <兄> <兄>
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.
ZOOが接続を確立すると、BARDはHARKコマンドを送信する必要があります。 A2、A3、A4、A5とは音節をアクセントにする必要があります。 U1、U2、U3、U4、U5とはアクセントしてはいけません。
PRITHEE <A2> <U3> <A3> <U4> <A4> <U5> <A5>
BRZ <AA> <行為> <行為> <4> <a 4> <兄> <兄>
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.
ZOOは今後のトランスクリプトを指定するRECEIVETHコマンドを使用する場合、BARDはPRITHEEで応答しなければなりません。 A2、A3、A4、A5とは音節をアクセントにする必要があります。 U3、U4、U5とはアクセントしてはいけません。
REGRETTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
DTT <AA> <行為> <行為> <4> <a 4> <兄> <兄>
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.
BARDが別館に写しを持っていない場合、それはZOOに通知するREGRETTETHコマンドを使用しています。 A2、A3、A4、A5とは音節をアクセントにする必要があります。 U3、U4、U5とはアクセントしてはいけません。
ACCEPTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
Oksptt <AA> <行為> <行為> <4> <a 4> <兄> <兄>
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が別館に写しを設置している場合、それはZOOに通知する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).
これはZOO（サンディエゴ）はBARD（ウィリアム）への転写産物を送信するサンプルIAMBペントセッションです。
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
ウィリアム>今HARK、向こうウィンドウブレークを通じてどのような光？サンディエゴ> RECEIVETH TRANSCRIPT SanDiego.BoBo.17ウィリアム> PRITHEEあなたの猿の知恵は述べpoureth！サンディエゴ> ANON 96サンディエゴ>私は唯一の種類であることを、残酷でなければなりません。このように悪い始まり、正面に悪化したままです。ウィリアム> REGRETTETHなしはサンディエゴ> ABORTETH運命の前にあなたの言葉は一日私のゾーンを祝福してくださったん令状
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）のためのプロトコルの説明です。 ZOOはCRITICによるレビューのために猿の転写産物を送信するために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は、コネクション型のプロトコルです。 ZOO（「洗っていない大衆」）は、バックZOOに応答を送信しCRITIC（「全能」）に要求を送信します。
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.
ZOOは、指定されたテキストを使用してCRITICに素敵な何かを言うことがあります。評論家のプロトコル内の褒め言葉に反応しません。しかし、一般的に評論家ZOOは多くの賛辞を使用するときに、新しい転写物を受け入れる可能性が高いと考えられています。
TRANSCRIPT <name> <size>
TRANSCRIPT <名前> <サイズ>
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.
ZOOはレビューのために、新たな転写産物のCRITICに通知します。転写産物、プラスの文字数の名前は、このリクエストのパラメータとして指定されています。トランスクリプトのテキストは、次に送信されます。
THANKS
THANKS
This is an indicator that a ZOO is about to terminate the connection.
これはZOOが接続を終了しようとしている指標です。
SIGH <insult>
SIGH <侮辱>
When the ZOO establishes a connection, the CRITIC must respond with a SIGH and an optional insult.
ZOOが接続を確立すると、CRITICはSIGHとオプションの侮辱で応答しなければなりません。
IMPRESS_ME
私を感動させる
A CRITIC must respond with an IMPRESS_ME once a ZOO has made a TRANSCRIPT request.
ZOOはTRANSCRIPT要求を行った後、評論家IMPRESS_MEで応答しなければなりません。
REJECT <code> REJECT 0 <text>
REJECTの<code> REJECT 0 <テキスト>
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.
トランスクリプトを受信した場合、CRITICはREJECTと拒否の理由を示すコードで応答しなければなりません。拒否コードのテーブルが以下に提供されます。コードが0のとき、CRITICはフリーテキストを使用して応答することができます。 CRITICは、それが受信または転写物のフルテキストを処理しています前に、REJECT送ることができます。
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
物欲しげ承諾
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のこのバージョンでサポートされていません。無限猿プロトコルスイート（弱虫）のためのワーキンググループは、利用可能な場合REJECT CRITICが今までこの応答を使用する可能性はほとんどありませんということで合意しました。これは、唯一の批評家がどのように動作するかを十分に理解していない実装者への説明として含まれています。時間では、評論家（猿がかもしれないとほぼ同じように）進化する可能性があります。今までに来るような時間は、弱虫は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.
CRITICが0の拒否コードを使用する場合は、テキスト形式の応答は評論家によって選択された暗号化方式を使用する必要があります。 PANプロトコルはZOOが使用されているどのような方式で決定することができる方法を指定していないので、ZOOはCRITICの応答を理解することができない場合があります。
Below is a sample session from a ZOO (SanDiego) to a CRITIC (NoBrainer).
以下CRITIC（NoBrainer）にZOO（サンディエゴ）からのサンプルセッションがあります。
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は> SIGH私たちはあなたの仕事を愛し、ここサンディエゴ>賛辞を入力してすべての人の希望を放棄します。あなたの言葉は、サンディエゴ>賛辞の宝石のようであり、あなたは常に正しいです。サンディエゴ> TRANSCRIPT RomeoAndJuliet.BoBo.763 251 NoBrainer> IMPRESS_MEサンディエゴ>二世帯、我々は新しい反乱、サンディエゴ>市民の血なりに古代の恨みブレークから私たちのシーン、サンディエゴ>を築く公正なヴェローナでは、>、尊厳で似サンディエゴの両方市民の手汚れました。サンディエゴ>これらの二つの敵の致命的な腰などからサンディエゴ>スターcross'd愛好家のペアは、自分の命を奪います。 NoBrainer> REJECT 2（ "これは、これまでに販売することはありません。"）サンディエゴ> THANKS 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.
動物の人道的処理の原理によれば、IMPSの設計は、特に直接SIMIANに接触し、その感情を傷つけるからCRITICを禁止します。吟遊詩人や評論家もあるため基本的な非互換性と設計上の欠陥で分離されています。
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.
IMPSの残りのためのセキュリティ上の考慮事項は、元のインターネットプロトコルのためのものと同様です。具体的には、IMPSは、過去の過ちから学ぶことを拒否し、軽率目をバッティングすることなく、同じエラーが繰り返されます。信頼できないエンティティがIMPSネットワークにアクセスする場合はなりすましやサービス拒否攻撃がたくさんあります。すべての送信は、暗号化せずに平文で発生するので、ネットワークは評論家以外のエンティティが含まれていない限り、革新的な作品は重大な問題ではありません盗難、対象となります。 IAMB-PENTメッセージに関して吟遊詩人のオープンな性質は、BARDが送信worksから重く借りすることができますが、デザインの吟遊詩人によってあからさまな転写物を盗むことができません。
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.
ZOOは、世界中からの擬似サルによる搾取に開いたままにすることができます。第三者は、パケットでSIMIANをフラッディングパケットごとに1メッセージIDをインクリメントして動物園およびサルの間の通信を中断する可能性があります。もっとheinously、当事者は、このようZOOを通じてサービスの大規模な拒否を引き起こし、各SIMIANに単一STOPリクエストを送信することにより、KEEPERプロトコルを悪用する可能性があります。当事者はまたCHIMP要求を偽造や、ZOOがまだ正常に機能している猿を交換しようとする可能性がありDEAD状態、など虚偽の情報を送信することができます。
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.
ZOOが繰り返し（特に食料、水、および獣医用）SIMIANの要求を拒否した場合に加えて、その後、ZOOが誤ってその特定のSIMIANに対するサービスの独自の拒否を引き起こす可能性があります。しかし、KEEPERとCHIMP両方はZOOが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.
彼らは確実に働くことを防ぎ克服できない財政問題や低優先順位付けを、直面しているので、すべてのバードは、本質的に安全です。 BARD実装はこれらの障害を克服する稀な場合には、15分間のみ成功し、その直後に[14]安全でないことに戻ります。 CRITICが大幅に適切なPAN応答でBARDの成功を減らすことができるので、これはバードと批評家は常に互いに別々に維持されなければならない理由はもう一つの理由です。
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?
非常に少数の人々は、ほとんどの評論家の実装、及び自体が本質的に安全では評論家を気にすることが期待されます。そのため、セキュリティが批評家のための優先順位ではありません。あまりにも多くのサルが同時に転写産物を提出した場合CRITICは、サービス拒否攻撃の犠牲者になることがあります。加えて、1つSIMIANは別のSIMIAN（これは剽窃問題と呼ばれる）をスプーフィングすることにより、非革新的な作業を提出することができます。 CRITIC応答も詐称することができますが、PANバージョン1でサポートされている唯一の応答が拒否であることから、これはあまり重要です。 GRUDGING_ACCEPTANCE応答が許可されている場合は注意が将来のバージョンで取られなければなりません。最後に、転写産物は、伝送中に失われる可能性があり、かつPANはこれが起こったかどうかを決定するZOOのためのメカニズムを提供しません。 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].
近年で発見パケットレベルの脆弱性の数に基づいて、それは間違ったパディングまたは予約ビット[15] [16] [17]と不正なIMPSのパケットを処理する際にいくつかの実装が非常に悪い動作します当然の結論です。
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.
著者は、アクセントのために宇宙全体、ウィリアム・シェイクスピアの本質を明確にするためのシェークスピアの文法、Rohnブレイクの講義のために、このドキュメントのサイズを三倍に技術的なコメントは、キーンカウフマンとアマンダVizedomのためのアンドレFRECHに感謝したい番号16、および黄色。
[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.クラーク、スタークミルビール、マンチェスター、NH、USA。 2月18日、2000年（私信）。 「良い質問！私はそのことを考えたことがない！私は賭け誰もがいずれか、持っていない。フライドポテトを渡してください。」
[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] "生地再MI、" ブレイディバンチ。オリジナル放送日1972年1月14日。
[6] Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.
[6]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7]ポステル、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]ブラウン、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]インターネットドラフト、バーンスタイン - 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]グラスマン、S.、Manasse、M.及びJ.モーグル、 "Y10K及び越え"、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.
1994作者不明年頃様々なUSENETの投稿では、[12] .signature、。
[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。 CERT。 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。 CERT。 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。 CERT。 1996年12月http://www.cert.org/advisories/
[18] All issues of TV Guide published between 1956 and the date of this document.
TVガイドの[18]すべての問題は、1956年から、この文書の日付の間に公開しました。
SteQven M. Christey EMail: steqve@shore.net
SteQven M. Christey Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。