はじめに

この文書は RFC2795 を勉強と好奇心のため適当に訳したものです。
翻訳の正確さは全く保証しません。
誤字誤訳等の指摘はいつでも大歓迎です。

この RFC は、いわゆる「無限の猿定理」を実装するときのためのプロトコル群を規定しています。

The Infinite Monkey Protocol Suite (IMPS)（無限サルプロトコルスイート(IMPS)）

Network Working Group
Request for Comments: 2795
Category: Informational

S. Christey
MonkeySeeDoo, Inc.
1 April 2000

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.

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

1. Introduction（序章）

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 (Infinite Monkey Protocol Suite; 無限サルプロトコルスイート) はサルの成果物を収集、転送し、歴史的な正確さ (シェイクスピア作品の場合) または革新性 (新しい作品の場合) をレビューする方法を規定した、実験的なプロトコル群である。
また、通常のサルのメンテナンスをするための基本的な通信フレームワークも提供する。

2. Objects in the Suite（スイート内のオブジェクト）

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 つある。
サルのグループは、ZOO (Zone Operations Organizations; 領域操作組織; 訳注：動物園と掛けている) に物理的に配置されている。
ZOO はサルとその装備を維持し、サルのタイプライターから成果物を取得し、成果物を評価する他のエンティティとやり取りする。

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 (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node; 半統合型猿インターフェース擬人化ノード; 訳注：類人猿と掛けている) は、サルに物理的に取り付けられたデバイスである。
サルとその 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 は CHIMP (Cross-Habitat Idiomatic Message Protocol; 生息地横断型慣用的メッセージプロトコル; 訳注：チンパンジーと掛けている？) を使用して ZOO と通信する。
ZOO は、KEEPER (Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources; 生態系資源のための知識と効率的なエミュレーションプロトコル; 訳注：飼育係と掛けている) を使用して、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.

ZOO は SIMIAN からタイプライターの成果物を取得し、非デジタルタイプライターが使用されている場合には、サルがタイプしたテキストを電子形式に変換する役割を果たす。
その後、ZOO は、成果物の内容をレビューするために、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.

シェイクスピアの作品や、すでに出版されている他の古典文学については、ZOO は成果物を BARD (Big Annex of Reference Documents; 参考文献の巨大別館; 訳注：吟遊詩人に掛けている) に転送する。
BARD は、成果物が別館の 1 つまたは複数の文書と一致するかどうかを判断する。
ZOO は、IAMB-PENT(Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts; 成果物の新古典的評価のための別館間のメッセージ同報プロトコル; 訳注：シェイクスピアが愛用したリズムである、弱強五歩格に掛けている) を使用して BARD に成果物を送信する。
成果物は、(a) 元の紙媒体ではなく電子媒体で転送され、(b) 「古典」という言葉が文字 N で始まらないため、新古典派とみなす (訳注：略語を IAMB-PENT にするために、無理やり 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 (Collective Reviewer's Innovative Transcript Integration Center; レビュアー集団の革新的成果物統合センター; 訳注：評論家に掛けている) に提出する。
CRITIC は、成果物が出版するのに値するほど革新的であるかどうかを判断する。
ZOO は、PAN (Protocol for Assessment of Novelty; 新規性評価プロトコル; 訳注：「否定的な意見を述べる」という意味に掛けているのだと思う) を使用して CRITIC と通信する。
PAN を使用して成果物を CRITIC に送信するプロセスは、フォアシャドウイング（伏線）と呼ばれることがある。

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 *
                *         *     *         *
                -+-+-+-+-+-     -+-+-+-+-+-

3. IMPS Packet Structure（IMPS パケットの構造）

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].

バージョン(Version)、シーケンス番号(Seq #)、プロトコル番号(Protocol #)、および予約(Reserved)フィールドは、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 オブジェクトの識別子である。
これらは、無限TAG(訳注：後述の I-TAG)を使用して表される (次章を参照)。

The Data section contains data which is of arbitrary length.

データ(Data)部には、任意の長さのデータが含まれる。

The Size field records the size of the entire packet using Infinite TAG encoding.

サイズ(Size) フィールドは、無限TAGエンコーディングを使用してパケット全体のサイズを記録する。

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 ビットの余分なパディング(Padding)が含まれる場合がある。

4. Infinite Threshold Accounting Gadget (I-TAG) Encoding（無限しきい値記録器エンコーディング）

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 内で一意の識別子が必要である。
この章では、I-TAG(Infinite Threshold Accounting Gadget; 無限しきい値記録用器) と呼ばれる 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) 原子よりも小さいサル、および/または複数の宇宙を利用する可能性のある 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.

ネットストリング、つまり自身のサイズを符号化する文字列が検討された。
ただし、ネットストリングは標準として受け入れられておらず、無限に拡張することもできない。
[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 倍以上にメモリを浪費する。
これは、無数のサルをサポートするのに十分なリソースがある環境では重要ではないように見えるかもしれないが、サルの識別という目的ではエレガントではない。
また、そのような表現を 2 進数に変換するのは CPU に負荷がかかる (少なくとも、LISP、Perl、および Java の組み合わせで作成された著者の実装に基づくと)。
アルゴリズムは複雑であり、不適切な実装につながる可能性がある。
最後に、本文書の著者は、RFC を適切に含めるには手遅れになるまで、その RFC のことを忘れていた。
ただし、サルがこの特定の章を入力し、CRITIC に提出した場合、おそらく車輪の再発明を意味する PAN 拒否コードを受け取ることに注意すること。

Since there is no acceptable representation for I-TAGs available, one is defined below.

I-TAG の表現方法として、許容可能なものがないため、以下に定義する。

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.

META-SIZE is an arbitrary length sequence of N '1' bits terminated by a '0' bit, i.e. it has the form:

SIZE は、任意の整数である ID を表すために使用されるバイト数を指定する。
META-SIZE は、SIZE を表すために使用されるビット数の上限を指定する。

META-SIZE は、「0」のビットで終了する N 個の「1」ビットの任意の長さのシーケンスであり、次の形式を有する:

       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は、IDを格納するのに必要なバイト数 (SIZE) を表すのに必要なビット数を 2^N が超えるような最小の数である。

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.

この表現は不格好ではあるが、メモリを効率的に使用し、無限大に拡張可能である。
2^N より小さい数 X (任意の N) に対しては、最大で (N + log(N) + log(log(N)))/8 バイトが X を表現するために必要となる。
計算が若干間違っている可能性もあるが、正しいように思える。

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-TAG 処理を実装するために、驚くほど洗練された小さな C 関数が作成されたが、この余白に含めるにはコード行が多すぎる [11]。

5. KEEPER Specification（KEEPER の仕様）

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.

以下は、ZOO が SIMIAN と通信するために使用する、生態系資源のための知識と効率的なエミュレーションプロトコル (KEEPER) の説明である。
KEEPER の IMPS プロトコル番号は 1 である。

KEEPER is a connectionless protocol.
The ZOO sends a request to the SIMIAN using a single IMPS packet.
The SIMIAN sends a response back to the ZOO with another IMPS packet.
The data portion of the packet is of the following form:

KEEPER はコネクションレス型プロトコルである。
ZOO は、単一の IMPS パケットを使用して SIMIAN にリクエストを送信する。
SIMIAN は別の IMPS パケットでレスポンスを ZOO に送り返す。
パケットのデータ部分は次の形式である。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version  | Type | Message ID    | Message Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version, Type, Message ID, and Message are all 16-bit integers.

バージョン(Version)、タイプ(Type)、メッセージ ID(Message ID)、およびメッセージ(Message Code)はすべて 16 ビット整数である。

Version = the version of KEEPER being used (in this document, the version is 1)

Version = 使用している KEEPER のバージョン (本文書では、バージョンは 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

Message ID = 異なるメッセージを区別するための一意の識別子

Message Code = the specific message being sent

Message Code = 送信される特定のメッセージ

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 レスポンスを送信する必要がある。

5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN)（KEEPER メッセージリクエストコード(ZOO から SIMIAN)）

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

コード	名前	説明
0	RESERVED	予約済
1	STATUS	サルのステータスを判定する
2	HEARTBEAT	サルに心拍があるかを確認する
3	WAKEUP	サルを目覚めさせる
4	TYPE	サルがタイピングしているか確認する
5	FASTER	サルにもっと速くタイピングさせる
6	TRANSCRIPT	成果物を送信させる
7	STOP	全てのサルの業務を終了させる
8-512	FUTURE	将来使用のために予約済
513+	USER	ユーザー定義

5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO)（KEEPER メッセージレスポンスコード(SIMIAN から ZOO)）

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

コード	名前	説明
0	RESERVED	予約済
1	ASLEEP	ステータス: サルは寝ている
2	GONE	ステータス: サルはタイプライター前にいない
3	DISTRACTED	ステータス: サルは気が散っている(タイプしていない)
4	NORESPONSE	ステータス: サルは反応しない
5	ALIVE	ステータス: サルは生きている
6	DEAD	ステータス: サルは死んでいる
7	ACCEPT	サルはリクエストを受け入れた
8	REFUSE	サルはリクエストを拒否した
9-512	FUTURE	将来使用のために予約済
513+	USER	ユーザー定義

5.3 Requirements for KEEPER Request and Response Codes（KEEPER リクエストコードとレスポンスコードの要求事項）

Below are the requirements for request and response codes within KEEPER.

A SIMIAN must respond to a STATUS request with an ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, or NORESPONSE code.

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.

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.

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.

A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD.

A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.

以下は、KEEPER におけるリクエストおよびレスポンスコードの要求事項である。

SIMIAN は STATUS リクエストに対して、ALIVE、DEAD、ASLEEP、GONE、DISTRACTED、または NORESPONSE コードでレスポンスする必要がある。
SIMIAN は HEARTBEAT リクエストに ALIVE または DEAD コードでレスポンスする必要がある。 SIMIAN の実装者は、超越瞑想やヨガを実践している非常にリラックスしたサルの心拍をチェックする場合、生きていても死んでいるように見える可能性があるため、注意する必要がある。
SIMIAN は STOP リクエストに NORESPONSE、ALIVE、DEAD、または GONE コードでレスポンスする必要がある。 SIMIAN がサルを停止する方法は、実装固有である。ただし、SIMIAN はサルの ALIVE ステータスを保持して、ZOO が当局や動物愛護団体によって閉鎖されるのを防ぐ必要がある。サルが存在するが、SIMIAN インターフェイスがサルが ALIVE か DEAD かを確認できない場合、NORESPONSE を使用する必要がある。
特に期限がある場合、SIMIAN は TYPE または FASTER リクエストに ACCEPT コードでレスポンスする必要がある。他に許可されている応答は、REFUSE、ASLEEP、GONE、NORESPONSE、または DEAD である。このプロトコルは、SIMIAN が REFUSE で応答した場合に取るべきアクションを定義していないが、将来のバージョンで BRIBE_BANANA コマンド（訳注：賄賂としてバナナを贈る？）が追加される可能性がある。
SIMIAN は WAKEUP リクエストに、ACCEPT、REFUSE、GONE、NORESPONSE、または DEAD で応答する必要がある。
SIMIAN は TRANSCRIPT リクエストに、成果物を ZOO に送信するために CHIMP セッションを確立することにより、レスポンスする必要がある。

5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER（KEEPER を使用した ZOO から 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.

ZOO (SanDiego) が BoBo という名前のサルとやり取りする必要があるとする。
KEEPER を使用して、SanDiego は BoBo の SIMIAN (BoBoSIM) とインターフェースする。
BoBo が自己認識と独立性を進化させ始めると、次のような通信が行われる可能性がある。

   SanDiego> STATUS
   BoBoSIM>  DISTRACTED
   SanDiego> TYPE
   BoBoSIM>  REFUSE
   SanDiego> TYPE
   BoBoSIM>  REFUSE
   SanDiego> TYPE
   BoBoSIM>  GONE

The following exchange might take place early in the morning, if BoBo was being poorly maintained and was working at its typewriter very late the night before.

次の通信は、BoBo のメンテナンスが不十分で、前夜遅くまでタイプライターで作業していた場合の早朝に行われる可能性がある。

   SanDiego> WAKEUP
   BoBoSIM>  NORESPONSE
   SanDiego> WAKEUP
   BoBoSIM>  NORESPONSE
   SanDiego> WAKEUP
   BoBoSIM>  NORESPONSE
   SanDiego> HEARTBEAT
   BoBoSIM>  DEAD
   SanDiego> TRANSCRIPT

6. CHIMP Specification（CHIMP の仕様）

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 が ZOO との通信に使用する生息地横断型慣用的メッセージプロトコル (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 (クライアント) は一連のリクエストを ZOO (サーバー) に送信し、ZOO (サーバー) は SIMIAN にレスポンスを返す。

6.1. SIMIAN Client Requests（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 が特定のリソースを要求している。
リソースは、FOOD、WATER、MEDICINE、VETERINARIAN、または TECHNICIAN の場合がある（訳注：順に、食べ物、水、薬、獣医、技術者）。
SIMIAN は、サルの行動と環境（例えば食糧皿）を解釈することによって、FOOD または WATER を要求する。
サルの健康状態が何らかの形（例えば手首またはお尻の痛み）で低下していることを観察した場合、MEDICINE または VETERINARIAN を要求する。
SIMIAN の正常性を判断する方法は、実装によって異なる。
SIMIAN 自体が故障している可能性がある場合、TECHNICIAN を要請する場合がある。

   REPLACE <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.

ZOO は、タイピング活動中にサルが使用するアイテムを交換する必要がある。
交換するアイテムは、TYPEWRITER、PAPER、RIBBON、CHAIR、TABLE、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 は ZOO にアイテムをクリーニングするよう要求している。
アイテムは、CHAIR、TABLE、または MONKEY の場合がある。
ZOO がアイテムをクリーニングする方法は実装固有である。
このコマンドがプロトコルで規定されているのは、無限匹のサルが無限台のタイプライターの前に座っていると、その臭いに耐えられないという理論があるからである [12]。
この理論が正しいことが証明された場合、CLEAN はプロトコルスイート全体で最も重要なコマンドになる可能性がある。

   NOTIFY <status>

The SIMIAN notifies the ZOO of the monkey's status.
The status may be any status as defined in the KEEPER protocol, i.e. ASLEEP, GONE, DISTRACTED, NORESPONSE, ALIVE, or DEAD.

SIMIAN は、サルの状態をZOOに通知する。
状態は、KEEPER プロトコルで定義された状態、すなわち ASLEEP、GONE、DISTRACTED、NORESPONSE、ALIVE、または DEAD のいずれかだろう。

   TRANSCRIPT <size>

The SIMIAN notifies the ZOO of a new transcript from the monkey.
The number of characters in the transcript is specified in the size parameter.

SIMIAN はサルからの新しい成果物を ZOO に通知する。
成果物の文字数は size パラメータで指定する。

BYE

The SIMIAN is terminating the connection.

SIMIAN は接続を終了する。

6.2. ZOO Server Responses（ZOO サーバーレスポンス）

   HELO <free text>

Upon initial connection, the ZOO must send a HELO reply.

最初の接続時に、ZOO は HELO レスポンスを送信する必要がある。

   ACCEPT

The ZOO will fulfill the SIMIAN's request.

ZOO は SIMIAN の要求を満たす。

   DELAY

The ZOO will fulfill the SIMIAN's request at a later time.

ZOO は SIMIAN の要求を、しばらくしてから満たす。

   REFUSE

The ZOO refuses to fulfill the SIMIAN's request.

ZOO は SIMIAN の要求を満たすことを拒否する。

   RECEIVED

The ZOO has received the full text of a transcript that has been submitted by the SIMIAN.

ZOO は、SIMIAN から提出された成果物の全文を受け取った。

6.3 Example SIMIAN-to-ZOO Session using CHIMP（CHIMP を使用した SIMIAN から ZOO へのセッション例）

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 インターフェイスを備えたサルの BoBo と、SanDiego という名前の ZOO を想定する。
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

7. IAMB-PENT Specification（IAMB-PENT の仕様）

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 (クライアント) は成果物フレーズを BARD (サーバー) に送信する。BARD は成果物を評価し、成果物が古典作品のすべてまたはその一部と一致するかどうかを ZOO に通知する。

7.1. ZOO Client Requests（ZOO クライアントリクエスト）

   RECEIVETH <transcript name>

The ZOO notifies the BARD of a new transcript to be evaluated.
The name of the transcript is provided.

ZOO は、BARD に評価対象の新しい成果物を通知する(訳注：RECEIVETH は受け取りの意味？)。
成果物の名前が提供される。

   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.

ZOO は、指定されたサイズの成果物をすぐに提供することを BARD に通知する(訳注：ANON はすぐにの意味？)。
次に、成果物のテキストが送信される。

   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.

ZOO は、コネクションをクローズしようとしていることを BARD に通知する(訳注：ABORTETH は中止の意味？)。
ZOO は終了メッセージを指定する必要がある。
A2、A3、A4、および A5 の音節にはアクセントを置かなければならない。
U3、U4、および U5 にアクセントを置いてはならない。

（訳注：多分、ABORTETH も含めて弱強五歩格の韻律にしろ、ということだと思う、自信なし）

7.2 BARD Responses（BARD レスポンス）

    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.

ZOO がコネクションを確立すると、BARD は 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.

ZOO が RECEIVETH コマンドを使用して次の成果物を指定する場合、BARD は PRITHEE (訳注：願望の意味？)でレスポンスする必要がある。
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.

別館に成果物と同じものが無かった場合、BARD は REGRETTETH コマンド(訳注：後悔の意味？)を使用して ZOO に通知する。
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.

BARD が別館に成果物を見つけた場合、ACCEPTETH コマンド(訳注：受け入れの意味？)を使用して ZOO に通知する。
A2、A3、A4、および A5 の音節にはアクセントを置かなければならない。
U3、U4、および U5 にアクセントを置いてはならない。

7.3 Example ZOO-to-BARD Session using IAMB-PENT（IAMB-PENT を使用した ZOO から BARD へのセッション例）

This is a sample IAMB-PENT session in which a ZOO (SanDiego) sends a transcript to a BARD (William).

これは、ZOO (SanDiego) が成果物を BARD (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

8. PAN Specification（PAN の仕様）

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 は PAN を使用して、CRITIC によるレビューのためにサルの成果物を送信する。
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 (「洗浄されていない大衆」) は、CRITIC (「全能の」) にリクエストを送信し、CRITIC は ZOO にレスポンスを返す。

8.1. ZOO Requests（ZOO リクエスト）

   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 に何か良いことを言うかもしれない。
CRITIC は、プロトコル内では賛辞に反応しない。
ただし、ZOO が多くの賛辞を使用する場合、CRITIC は新しい成果物を受け入れる可能性が高いと一般的に考えられている。

   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.

ZOO は CRITIC にレビュー用の新しい成果物を通知する。
成果物の名前と文字数を、このリクエストのパラメータとして指定する。
次に、成果物のテキストが送信される。

   THANKS

This is an indicator that a ZOO is about to terminate the connection.

これは、ZOO がコネクションを終了しようとしていることを示している。

8.2. CRITIC Responses（CRITIC レスポンス）

   SIGH <insult>

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 リクエストを送信したら、CRITIC は IMPRESS_ME (訳注：私を驚かせたor感動させた？)でレスポンスする必要がある。

   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.

成果物を受け取ったら、CRITIC は REJECT と拒否の理由を示すコードで応答する必要がある。
拒否コードの表を以下に示す。
コードが 0 の場合、CRITIC はフリーテキストを使用して応答できる。
CRITIC は、成果物の全文を受信または処理する前に REJECT を送信する場合がある。

   DONT_CALL_US_WE'LL_CALL_YOU

The CRITIC makes this statement before terminating the connection.

CRITIC は、コネクションを終了する前にこのステートメントを送る(訳注：「電話は掛けてこないでください。こちらから連絡します」の意)。

   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 ではサポートされていません。
無限サルプロトコルスイートワーキンググループ(The Working group for the Infinite Monkey Protocol Suite; WIMPS)は、REJECT が利用可能な場合に CRITIC がこの応答を使用する可能性は非常に低いことに同意した。
これは、CRITIC がどのように機能するかを完全に理解していない実装者への説明としてのみ含まれている。
いずれ、CRITIC が進化する可能性がある (サルとほぼ同じ方法で)。
そのような時が来れば、WIMPS は PAN の以降のバージョンでこの応答をサポートすることを決定するかもしれない。

8.3. Table of CRITIC Reject Codes（CRITICの拒否コード表）

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."

コード	説明
0	`<暗号化されたレスポンスが続く; 下記参照>`
1	「あなたは車輪を再発明している」
2	「これは絶対に売れません」
3	「は？私はこれを全く理解できません」
4	「あなたは 20 年前のちょっとあいまいな文献を 1 つ忘れているせいで、あなたのアイデア全体が無意味になっている」
5	「提出数が多かったため、すべての成果物を受け入れることができませんでした」
6	「チャートやグラフが足りない。色は使わないの？」
7	「私は不機嫌なので、あなたに八つ当たりをすることにした」
8	「私たちが求めている物はこれじゃない」
9	「独創性が足りないね」
10	「受付の期限を過ぎています。来年また挑戦してください」

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 を使用する場合、テキスト応答は CRITIC によって選択された暗号化スキームを使用する必要がある。
PAN プロトコルは、どのスキームが使用されているかを ZOO がどのように判断できるかを規定していないため、ZOO は CRITIC の応答を理解できない可能性がある。

8.4. Example ZOO-to-CRITIC Session using PAN（PAN を使用した ZOO から CRITIC へのセッション例）

Below is a sample session from a ZOO (SanDiego) to a CRITIC (NoBrainer).

以下は、ZOO (SanDiego) から CRITIC (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

9. Security Considerations（セキュリティに関する考慮事項）

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 の設計は、CRITIC が直接 SIMIAN に接触してその感情を傷つけることを明確に禁止している。
BARD と 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 ネットワークにアクセスすると、なりすましやサービス拒否攻撃が多発する。
すべての送信は暗号化されていない平文で行われるため、革新的な作品は盗まれる可能性があるが、ネットワークに CRITIC 以外のエンティティが含まれていない限り、これは重大な問題ではない。
IAMB-PENT メッセージに関する BARD のオープンな特性により、BARD は送信された成果物から大量に借用することができるが、設計上、BARD はトランスクリプトを完全に盗むことができない。

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 に悪用される可能性がある。
第三者は、SIMIAN にパケットを大量に送り込み、パケットごとにメッセージ ID を 1 ずつ増やすことで、ZOO と SIMIAN の間の通信を妨害することができる。
さらに凶悪なことに、彼らは各 SIMIAN に単一の STOP 要求を送信することで KEEPER プロトコルを悪用し、ZOO 全体で大規模なサービス拒否を引き起こす可能性がある。
彼らは、CHIMP リクエストを偽装したり、DEAD ステータスなどの誤った情報を送信したりすることもでき、これにより　ZOO はまだ正常に機能しているサルを置き換えようとする可能性がある。

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 のリクエスト(特にFOOD、WATER、VETERINARIAN)を繰り返し拒否する場合、ZOO はうっかりその特定の SIMIAN に対してサービス拒否を引き起こす可能性がある。
しかし、KEEPER と CHIMP は、NORESPONSE または DEAD 状態コードによって、ZOO がこの状態を適時に検出することを可能にしている。

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 は本質的に安全ではない。なぜなら、彼らは乗り越えられない財政問題と低い優先順位に直面しており、それが確実に機能することを妨げているである。
BARD 実装がこれらの障害を克服するまれなケースでは、15 分間しか成功せず、その後すぐに安全でない状態に戻る [14]。
CRITIC は適切な PAN レスポンスで BARD の成功を大幅に減らす可能性があるため、これが、BARD と CRITIC を常に互いに分離しておく必要があるもう 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?

CRITIC のほとんどの実装を気にする人はほとんどいないと予想され、CRITIC 自体は本質的に安全ではない。
したがって、セキュリティは CRITIC にとって優先事項ではない。
あまりにも多くの SIMIAN が同時に成果物を送信すると、CRITIC はサービス拒否攻撃の被害者になる可能性がある。
さらに、ある SIMIAN が別の SIMIAN になりすまして革新的ではない作品を提出する場合がある (これを剽窃問題と呼ぶ)。
CRITIC レスポンスもスプーフィングされる可能性があるが、PAN バージョン 1 でサポートされている唯一の応答は REJECT であるため、これはほとんど重要ではない。
GRUDGING_ACCEPTANCE 応答が許可される場合、将来のバージョンでは注意が必要である。
最後に、成果物は送信中に失われる可能性があり、PAN は ZOO が喪失が発生したかどうかを判断するメカニズムを提供しない。
IMPS の将来のバージョンは、この基本的な設計上の問題に答えるのにより適しているかもしれない: 革新的な作品が送信中に失われた場合、CRITIC はそれを PAN できるか？

Based on the number of packet-level vulnerabilities discovered in recent years, it is a foregone conclusion that some implementations will behave extremely poorly when processing malformed IMPS packets with incorrect padding or reserved bits [15] [16] [17].

近年発見されたパケットレベルの脆弱性の数に基づいて、不正なパディングまたは予約ビットを含む不正な IMPS パケットを処理する場合、一部の実装の動作が非常に悪くなることは当然の帰結である [15] [16] [17]。

Finally, no security considerations are made with respect to the fact that over the course of infinite time, monkeys may evolve and discover how to control their own SIMIAN interfaces and send false requests, or to compose and submit their own transcripts.
There are indications that this may already be happening [18].

最後に、サルは無限の時間の経過とともに進化し、自分の SIMIAN インターフェースを制御して偽のリクエストを送信する方法、または自分の成果物を作成して送信する方法を発見する可能性があるという事実に関して、セキュリティの考慮は行われていない。
これがすでに起こっている可能性があるという兆候がある [18]。

10. Acknowledgements（謝辞）

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 倍にしてくれた技術的なコメントについて Andre Frech に感謝したいと思う。シェークスピアの文法に関するレクチャーについて Kean Kaufmann と Amanda Vizedom に感謝します。宇宙全体の性質を明らかにしてくれた Rohn Blake と、アクセントと数字の 16 、そして黄色をくれた William Shakespeare に感謝します。

11. References

   [1]  The Famous Brett Watson, "The Mathematics of Monkeys and
        Shakespeare."  http://www.nutters.org/monkeys.html

   [2]  Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
        http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html

   [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."

   [4]  The author was unable to find a reference in any issue of TV
        Guide published between 1956 and the date of this document.

   [5]  "Dough Re Mi," The Brady Bunch.  Original air date January 14,
        1972.

   [6]  Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.

   [7]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [8]  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
        Relay", STD 55, RFC 2427, September 1998.

   [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.

   [10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC
        2550, 1 April 1999.

   [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.

   [12] .signature in various USENET postings, circa 1994.  Author
        unknown.

   [13] "Recognizing Irony, or How Not to be Duped When Reading."
        Faye Halpern.  1998.
        http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm

   [14] Andy Warhol.  Circa 1964.

   [15] CERT Advisory CA-98-13.  CERT.  December 1998.
        http://www.cert.org/advisories/

   [16] CERT Advisory CA-97.28.  CERT.  December 1997.
        http://www.cert.org/advisories/

   [17] CERT Advisory CA-96.26.  CERT.  December 1996.
        http://www.cert.org/advisories/

   [18] All issues of TV Guide published between 1956 and the date of
        this document.

12. Author's Address

   SteQven M. Christey
   EMail: steqve@shore.net

13. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   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.