Network Working Group S. Christey Request for Comments: 2795 MonkeySeeDoo, Inc. Category: Informational 1 April 2000 無限猿プロトコルスィート(IMPS) The Infinite Monkey Protocol Suite (IMPS) このメモの位置づけ このメモはインターネットコミュニティに情報を提供する。いかなる種類 のインターネットの標準も規定するものではない。このメモの配布は制限 しない。 著作権の表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 概要 このメモは、いつウィリアム＝シェイクスピアの劇全体またはすばらしい テレビのショーができあがるかを決定する目的で無限個のタイプライター の前に座った無限匹の猿をサポートするプロトコルスィートを記述する。 このスィートは猿に対するコミュニケーションと制御のプロトコルと猿と 相互作用する組織を含む。 目次 1. 序論 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. スィート中のオブジェクト . . . . . . . . . . . . . . . . . 2 3. IMPS パケットの構造 . . . . . . . . . . . . . . . . . . . 4 4. 無限閾値アカウンティングガジェット(I-TAG) エンコード . . . 5 5. KEEPER の仕様 . . . . . . . . . . . . . . . . . . . . . . 6 5.1 KEEPER メッセージの要求コード (ZOO-to-SIMIAN) . . . . . 7 5.2 KEEPER メッセージの回答コード (SIMIAN-to-ZOO) . . . . . 8 5.3 KEEPER の要求・回答コードに対する要請 . . . . . . . . . 8 5.4 KEEPER を使った ZOO-to-SIMIAN の交換の試行 . . . . . . . 9 6. CHIMP 仕様 . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 SIMIAN クライアント要求 . . . . . . . . . . . . . . . . 10 6.2 ZOO サーバー回答 . . . . . . . . . . . . . . . . . . . . 11 6.3 CHIMP を使った SIMIAN-to-ZOO セッションの試行 . . . . . 11 7. IAMB-PENT の仕様 . . . . . . . . . . . . . . . . . . . . . 12 7.1 ZOO クライアント要求 . . . . . . . . . . . . . . . . . . 12 7.2 BARD 回答 . . . . . . . . . . . . . . . . . . . . . . . 12 7.3 IAMB-PENT を使った ZOO-to-BARD セッションの試行 . . . . 13 8. PAN の仕様 . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 ZOO の要求 . . . . . . . . . . . . . . . . . . . . . . . 14 8.2 CRITIC の回答 . . . . . . . . . . . . . . . . . . . . . 14 Christey Informational [Page 1] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 8.3 CRITIC の拒絶コードの表 . . . . . . . . . . . . . . . . 15 8.4 PAN を使った ZOO-to-CRITIC セッションの試行 . . . . . . 16 9. セキュリティの考察 . . . . . . . . . . . . . . . . . . . 16 10. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 18 12. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . 19 13. 完全な著作権の表示 . . . . . . . . . . . . . . . . . . . 20 1. 序論 無限匹の猿が無限個のタイプライターの前に座り、ランダムにキーを押し たら、たまたま完全なシェイクスピアの作品を作り出していたと仮定する [1] [2]。しかし、もしこのような偉業がなされるとしても、このことをど うやって知ることができるだろうか。また、猿がシェイクスピアの作品を エスペラントに完璧に翻訳していたとしたらどうだろう。猿の基本的欲求、 たとえば睡眠や食事を賄いながら、このような作品を手にいれるシステム をどのようにして構築するのだろうか。これらの重要な問題に現実として 含まれるものをだれも取り扱ってこなかった [3]。 加えて、相当の努力がシェイクスピアにのみ向けられてきたとすれば膨大 な資源の無駄である。無限匹の働く猿により、猿が世界の貧困の終わらせ 方、病気の治療法、あるいはもっとも重要なテレビ用の良質な喜劇の書き 方に関する文書を作り出すことも同じくらいありうる [4]。このような環 境は、革新のためにうってつけであり、特別な技術的設計により、「世界 をもっと明るくする」のに実に役に立つだろう [5]。 無限猿プロトコルスィート(Infinite Monkey Protocol Suite (IMPS))はど のように猿の写しが集められ転送され、歴史上の的確さ(シェイクスピアの 作品の場合)または革新(新しい作品の場合)が評価されるかを規定する実験 的なプロトコルのセットである。また、通常の猿の面倒を見るための基本 的な通信の枠組みも提供する。 2. スィート中のオブジェクト IMPS ネットワークの中でやり取りする4つの一次エンティティがある。猿 の一群は物理的には Zone Operations Organizations (ZOOs) におかれる。 ZOO は猿と猿の使う装置を維持し、猿のタイプライターから写しを取得し、 その写しを評価する別のエンティティと交信する。 SIMIAN (半統合化された猿とインターフェースをとる擬人化されたノード (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node))は、猿に 物理的に接続された装置である。これは猿と ZOO との間の交信のためのイ Christey Informational [Page 2] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 ンターフェースを提供する。実質的には猿のための翻訳機である。猿の代 わりに、人間語を使って ZOO に対しステータスレポートや資源要求を送っ たり、ZOO の要求に回答したりする。 SIMIAN は生息地をまたいだ慣用的なメッセージプロトコル(Cross-Habitat Idiomatic Message Protocol (CHIMP))を ZOO と交信するために使う。ZOO は生態系資源のための賢くて有能なエミュレーションプロトコル (Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER)) を SIMIAN との交信のために使う。 ZOO は SIMIAN からタイプライターによる写しを取得する。SIMIANは、非 デジタル化タイプライターが使われている場合には猿が打ったテキストを 電子的なフォーマットに変換しなければならない。ZOO はその写しを、内 容を評価する1つ以上のエンティティに転送してもよい。IMPS はそのよう な2つの評価用プロトコルを定義している。ほかのものが付け加わるかもし れないが。 シェイクスピアの作品、または同じようにすでに出版されている古典文学 の作品用には、ZOO は写しを BARD(参照文献の大きな別館(Big Annex of Reference Documents)) に転送する。BARD はその写しが別館の中の1つ以 上の文献と一致するかどうかを決める。ZOO は新古典主義の写本を評価す るための別館の間でメッセージをブロードキャストするプロトコル (Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts) (IAMB-PENT) を使って BARD に写しを転送す る。その写しは (a) 原本の紙の代わりに電子的なメディアで転送されてい ること、(b) "classical" という語は "N" という文字を含まないことから 新古典主義(Neoclassical)のものであると考えられる。 新しい、そして潜在的に革新的な作品用には、ZOO は CRITIC(評論家のた めの革新的な写しの統合センター(Collective Reviewer's Innovative Transcript Integration Center)) に送る。CRITIC はその写しが出版する に堪えるような革新的なものかどうかを決める。ZOO は新しい物を評価す るためのプロトコル(Protocol for Assessment of Novelty) (PAN) を使っ て CRITIC を交信する。CRITIC に写しを送りために PAN を使うプロセス は予言として参照されることもある。 IMPS の概念図を以下に示す。非技術系の読者、例えば中間管理職、営業担 当、リベラルアートの大多数は次の2節は読み飛ばすことを勧める。この文 書の残りは上級管理職はもう読むのをやめてると思う。 (((訳注： ZOO:動物園 SIMIAN:類人猿 CHIMP:チンパンジー KEEPER:飼育係 BARD:詩人 CRITIC:評論家 PAN:天秤の皿、米国口語で「けなす」))) Christey Informational [Page 3] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 -+-+-+-+-+- CHIMP -+-+-+-+-+- | SIMIAN/ | ----------> * * | MONKEY | * ZOO * | | <---------- * * -+-+-+-+-+- KEEPER -+-+-+-+-+- / \ / \ IAMB-PENT / \ PAN / \ V V -+-+-+-+-+- -+-+-+-+-+- * * * * * BARD * * CRITIC * * * * * -+-+-+-+-+- -+-+-+-+-+- 3. IMPS パケットの構造 すべての IMPS プロトコルは以下に示すパケット構造を利用しなければな らない。 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| |Version | Seq # | Protocol # | Reserved | Size | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| | Source | Destination | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| | Data | Padding | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| Version, Sequence #, Protocol #, および Reserved は32ビットの符号な し整数である。IMPS version 1.0 では、Version は 1 でなければいけな い。Reserved は 0 でなければならず、将来においても常に 0 になるだろ う。これは、ほかのあらゆるプロトコルの仕様において「将来の使用」の ための reserved のフィールドを、けっして変更もしないし、また、バン ド幅と目盛の無駄であるけれども含めているので準備している[6] [7] [8]。 Source と distination は通信している IMPS オブジェクトのための識別 子である。これは無限 TAG(次節参照) を使って表現する。 Data セクションは任意の長さのデータを格納する。 Size フィールドは無限TAG エンコードによりパケット全体の長さを格納す る。 パケットの終端にはパケットのサイズが次のバイト境界にあうように 0 か ら 7 ビットの大きさの Padding を含むことができる。 Christey Informational [Page 4] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 4. 無限閾値アカウンティングガジェット (I-TAG) エンコード 個々の SIMIAN は IMPS で固有の識別子が必要である。この節では、無限 閾値アカウンティングガジェット(Infinite Threshold Accounting Gadget)(I-TAG) として参照される IMPs 識別子の設計について述べる。 I-TAG は任意の大きさの数値を表現することができる。 SIMIAN をユニークに識別するには、無限個の識別子を表現できる体系が必 要となる。すべての整数の組をコンパクトな表現として使うことができる。 しかし、あらゆる既存のプロトコルでは整数のために使われる最大のバイ ト数を規定することにより利用可能な整数に本質的に制限がある。この方 法では、無限匹の猿を管理する IMPS ネットワークをきちんと動作させる ことができない。 実際問題、既知宇宙にある原子の数よりも大きな整数を表現できるバイト サイズを使うこともできる。しかし、この手法はいくつかの制約がある。 (a) 原子以下のレベルの猿を扱う、または複数の宇宙に関して扱うまたは その両方をやろうとするような IMPS の実装をいわれなく排除してしまう こと。(b) この宇宙にどれだけの原子があるのかということについてコン センサスがとれていないこと。(c) 数字が物凄く大きいわりに無限に比べ れば哀れなほどに掛け離れていること。IMPS を完全に実装したものは無限 大の数を非常にうまく扱うので、IMPS はそれを表現できることを保証する。 netstrings つまり、それ自身の大きさをエンコードした文字列が考えられ る。しかし、netstrings は標準として受け入れられておらず、無限には届 かない。[9] に書かれているように、「999999999 バイトより大きいのは だめ」だ。Well put. 任意の日付を特定する手法も実装として考えられる。この方法は Y10K 問 題を解決し、無限大に到達するが、ASCII での表現は 8 よりも大きいファ クターにより目盛が無駄になる。このことは無限匹の猿をサポートするの に十分な資源があるような環境においては重大なことではないようである が、猿を特定するという目的には洗練されていない。(すくなくとも著者が LISP と Perl と Java を組み合わせて書いた実装に基づく)二進数にこの ような表現を変換することは CPU を酷使する。アルゴリズムはわかりにく く、誤った実装になりがちだ。結局、この文書の著者はそれを含めるのに は遅すぎるようになるまでにその RFC のことを忘れて、やはり感情的に I-TAG のアイデアに愛着を覚えた。しかし、猿がこの特定の節をタイプし CRITIC に送ったとしたら、たぶん「車輪の再発明」を意味する PAN の拒 否コードを受けただろうということに注意すべきだ。 Christey Informational [Page 5] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 実用になる I-TAG の受け入れられるような表現がなかったので、以下のよ うに定義した。 I-TAG は3つの節に分割される： |-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+| | META-SIZE | SIZE | ID | |-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+| SIZE は ID を表現するのにどれだけのバイト数を使うかを指定する。ここ で、ID は任意の整数である。META-SIZE は SIZE を表現するのに使われる ビット数の上限を規定する。 META-SIZE は '0' のビットで終端された N 個の '1' であるビットの任意 の長さの連続である。つまり次のような形になる。 11111...1110 ここで、N は 2^N が ID を格納するのに必要となるバイト数(つまり SIZE)を表現するのに必要となるビット数を超えるようなもののうち最小の 数である。 SIZE は N ビットを使ってエンコードされ、もっとも重要なビット(MSB)か らもっとも重要でないビット(LSB)の順に並ぶ。 最終的に、ID は SIZE バイトを使ってエンコードされる。 この表現は clunky だけれどもメモリの使用効率がよく、無限大にも到達 可能である。2^N (N は任意) よりも小さい適当な数 X に対し、X を表現 するのには、(N + log(N) + log(log(N)))/8 の最大値バイトが必要となる。 数学的には不正確かもしれないが正しそうに見える。 優れた、洗練された、小さい C の関数が I-TAG 処理を実装するために書 かれたが、このすきまに納めるのにはコードの行数が多すぎる [11]。 5. KEEPER の仕様 以下は、生態系資源のための賢くて有能なエミュレーションプロトコル (Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER)) に関する記述である。これは、ZOO が SIMIAN と交 信するのに使う。KEEPER の IMPS プロトコル番号は 1 である。 KEEPER はコネクションレスなプロトコルである。ZOO は単一の IMPS パケッ トを使って SIMIAN に対し要求を送る。SIMIAN は別の IMPS パケットで ZOO に回答を返す。パケットのうちのデータ部分は、次のような形式になっ ている。: Christey Informational [Page 6] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Message ID | Message Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version, Type, Message ID, Message はすべて 16 ビット整数である。 Version = 使われている KEEPER のバージョン(ここではバージョンは 1) Type = 送られたメッセージのタイプ。'0' が要求、'1' が回答。 Message ID = 異なるメッセージを判別するためのユニークな識別子 Message Code = 送られた特定のメッセージ ZOO が KEEPER 要求を送るとき、SIMIAN はもとの要求と同じ Message ID を使った KEEPER 回答を送らなければならない。 5.1 KEEPER メッセージの要求コード (ZOO-to-SIMIAN) CODE NAME DESCRIPTION +-----------------------------------------------------------+ | 0 | RESERVED | 予約 | +-----------------------------------------------------------+ | 1 | STATUS | 猿の状態を決める | +-----------------------------------------------------------+ | 2 | HEARTBEAT| 猿が生きているか確かめる | +-----------------------------------------------------------+ | 3 | WAKEUP | 猿を起こす | +-----------------------------------------------------------+ | 4 | TYPE | 猿がタイプをしているか確かめる | +-----------------------------------------------------------+ | 5 | FASTER | 猿にもっと速くタイプさせる | +-----------------------------------------------------------+ | 6 |TRANSCRIPT| 写しを送る | +-----------------------------------------------------------+ | 7 | STOP | あらゆる猿の仕事をやめる | +-----------------------------------------------------------+ |8-512 | FUTURE | 将来の使用のため予約 | +-----------------------------------------------------------+ | 513+ | USER | ユーザー定義 | +-----------------------------------------------------------+ Christey Informational [Page 7] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 5.2 KEEPER メッセージの回答コード (SIMIAN-to-ZOO) CODE NAME DESCRIPTION +-------------------------------------------------------------+ | 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 KEEPER の要求・回答コードに対する要請 以下は、KEEPER における要求・回答コードに対する要請である。 1. SIMIAN は STATUS 要求に対して ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, NORESPONSE のいずれかのコードを返さなければならない。 2. SIMIAN は HEARTBEAT 要求に対し、ALIVE または DEAD のコードを返さ なければならない。SIMIAN の実装者は、生きているとしても DEAD のよう に見えるかもしれないので、超自然的瞑想、すなわちヨガをしている非常 にリラックスした猿の鼓動(heartbeat)を調べるときは注意しなければなら ない。 3. SIMIAN は STOP 要求に対して、NORESPONSE, ALIVE, DEAD, GONE のい ずれかのコードを返さなければならない。SIMIAN が猿をどのように止める かは実装依存である。しかし、SIMIAN は ZOO が公権力または動物愛護団 体に閉鎖されるのを防ぐため猿の ALIVE の状態を保つべきだ。猿は存在し ているが、 SIMIAN インターフェースが猿が ALIVE か DEAD かを確かめら れない場合は、NORESPONSE を使わなければならない。 Christey Informational [Page 8] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 4. SIMIAN は TYPE 要求または FASTER 要求に対し、特にデッドラインが あるときは ACCEPT のコードを返すべきだ。ほかの許される回答は REFUSE, ASLEEP, GONE, NORESPONSE, DEAD のいずれかのみである。このプ ロトコルは、SIMIAN が REFUSE で回答したときどんな行動がとられるかは 定義しない。将来のバージョンで BRIBE_BANANA(賄賂のバナナ)コマンドが 付け加えられるかも知れないけれども。 5. SIMIAN は WAKEUP 要求に対し、ACCEPT, REFUSE, GONE, NORESPONSE, DEAD のいずれかのコードを返さなければならない。 6. SIMIAN は TRANSCRIPT 要求に対し ZOO に写しを送るための CHIMP セッ ションを確立することで回答しなければならない。 5.4 KEEPER を使った ZOO-to-SIMIAN の交換の試行 SanDiego という ZOO が BoBo と名付けられた猿と交信しなければならな いと仮定する。KEEPER を使って SanDiego は BoBo の SIMIAN(以下、 BoBoSIM)と交信するだろう。以下に続くやり取りは、BoBo が自意識と自立 を発達させた場合におきそうなものである。 SanDiego> STATUS BoBoSIM> DISTRACTED SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> REFUSE SanDiego> TYPE BoBoSIM> GONE 以下のやり取りは、早朝に、BoBo がきちんと維持されておらず、前の晩、 とても遅くまでタイプライターで働いていた場合におきそうなものである。 SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> WAKEUP BoBoSIM> NORESPONSE SanDiego> HEARTBEAT BoBoSIM> DEAD SanDiego> TRANSCRIPT 6. CHIMP の仕様 以下は、生息地をまたいだ慣用的なメッセージプロトコル(Cross-Habitat Idiomatic Message Protocol (CHIMP)) についての記述である。これは SIMIAN が ZOO とやり取りをするときに使うプロトコルである。CHIMP の IMPS プロトコル番号は 2 である。 Christey Informational [Page 9] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 CHIMP はコネクション指向のプロトコルである。SIMIAN (クライアント)は ZOO (サーバー) に対して一連の要求を送る。サーバーは SIMIAN に回答を 送る。 6.1. SIMIAN クライアント要求 SEND SIMIAN は特定の資源(resource)を要求している。資源は FOOD, WATER, MEDICINE, VETERINARIAN, TECHNICIAN (食糧、水、薬、獣医、技術者)の どれかであろう。SIMIAN は猿の行動や環境(例えば食事用の皿)を解釈し て FOOD または WATER の要求をする。何らかの理由、例えば手根管症候 群、お尻がヒリヒリするなど、により猿の健康が害されていることを観 察したら、MEDICINE または VETERINARIAN を要求する。SIMIAN がどの ようにして健康かどうかを決めるかは実装依存である。SIMIAN 自体が以 上になった場合には、TECHNICIAN を要求することもある。 REPLACE ZOO は猿がタイピングの活動をしている間に使ったアイテム(item)を交 換しなければならない。交換されるアイテムは、TYPEWRITER, PAPER, RIBBON, CHAIR, TABLE, MONKEY(タイプライター、紙、インクリボン、椅 子、机、猿) のいずれかになるだろう。 CLEAN SIMIAN は ZOO がアイテム(item)をきれいにすることを要求している。 アイテムは CHAIR, TABLE, MONKEY のどれかだろう。ZOO がアイテムを どのようにしてきれいにするかは実装依存である。このコマンドは無限 匹の猿が無限個のタイプライターの前に座ったらその臭いは我慢できな いだろう [12] ということが想定されたためにこのプロトコルに規定さ れた。この理論が正しいと証明されたら、CLEAN はこのプロトコルスィー ト全体においてもっとも重大なコマンドになるだろう。 NOTIFY SIMIAN は ZOO に猿の状態(status) を通知する。状態は KEEPER プロト コルの中で定義されたようなあらゆる状態、すなわち、ASLEEP, GONE, DISTRACTED, NORESPONSE, ALIBE, DEAD のいずれかである。 TRANSCRIPT SIMIAN は ZOO に猿から得た新しい写しの通知する。写しの中の文字数 が size パラメータで指定される。 Christey Informational [Page 10] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 BYE SIMIAN が接続を終了する。 6.2. ZOO サーバー回答 HELO <任意のテキスト> 接続のはじめに、ZOO は HELO 回答を送らなければならない。 ACCEPT ZOO は SIMIAN の要求を満たすだろう。 DELAY ZOO は後で SIMIAN の要求を満たすだろう。 REFUSE ZOO は SIMIAN の要求を拒絶する。 RECEIVED ZOO は SIMIAN が送った写しの全文を受け取った。 6.3 CHIMP を使った SIMIAN-to-ZOO セッションの試行 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 Christey Informational [Page 11] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 SanDiego> REFUSE BoBoSIM> NOTIFY NORESPONSE SanDiego> ACCEPT BoBoSIM> NOTIFY DEAD SanDiego> ACCEPT BoBoSIM> REPLACE MONKEY SanDiego> ACCEPT 7. IAMB-PENT の仕様 以下は、新古典主義の写本を評価するための別館の間でメッセージをブロー ドキャストするプロトコル (Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts) (IAMB-PENT) に関する記述で ある。ZOO が BARD に写しを送るのに使う。IMPS プロトコル番号は 5 で ある。 IAMB-PENT はコネクション指向のプロトコルである。ZOO(クライアント) は BARD(サーバー) に写しの一節を送る。BARD は写しを評価し、その写し が古典作品の全体または一部と一致したら ZOO に通知する。 7.1. ZOO クライアント要求 RECEIVETH ZOO は BARD に評価されるべき新しい写しがあることを通知する。写し の名前(transcript name)は提供される。 ANON ZOO は BARD に与えられたサイズ(size)の写しがすぐに提供されるはず であることを通知する。写しのテキストはその次に送られる。 ABORTETH ZOO は BARD に接続を今にも閉じるということを通知する。ZOO は切断 メッセージを指定しなければならない。A2, A3, A4, A5 の音節に強勢を 置かなければならない。U3, U4, U5 は強勢を置いてはならない。 7.2 BARD 回答 HARK ZOO が接続を確立したとき、BARD は HARK コマンドを送らなければな らない。A2, A3, A4, A5 の音節に強勢を置かねばならない。U1, U2, U3, U4, U5 には強勢を置いてはならない。 Christey Informational [Page 12] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 PRITHEE ZOO が次に来る写しを指定するために RECEIVETH コマンドを使うとき、 BIRD は PRITHEE で回答しなければならない。A2, A3, A4, A5 の音節 には強勢を置かなければならない。U3, U4, U5 には強勢を置いてはな らない。 REGRETTETH BARD が別館に写しを持っていない場合、ZOO に知らせるために REGRETTETH コマンドを使う。A2, A3, A4, A5 の音節には強勢を置かね ばならない。U3, U4, U5 には強勢を置いてはならない。 ACCEPTETH BARD が別館に写しを置いた場合、ZOO に知らせるために ACCEPTETH コ マンドを使う。A2, A3, A4, A5 の音節には強勢を置かなければならな い。U3, U4, U5 には強勢を置いてはならない。 7.3 IAMB-PENT を使った ZOO-to-BARD セッションの試行 これは ZOO(SanDiego) が BARD(William) に写しを送る、IAMP-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 の仕様 以下は、新しい物を評価するためのプロトコル(Protocol for Assessment of Novelty) (PAN) に関する記述である。ZOO は CRITC が評価するために 猿の写しを送るために PAN を使う。PAN の IMPS プロトコル番号は 10 で ある [13]。 PAN は接続指向のプロトコルである。ZOO(下層民) は CRITIC(権力者) に 要求を送る。CRITIC は ZOO に回答を返す。 Christey Informational [Page 13] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 8.1. ZOO の要求 COMPLIMENT ZOO は与えられたテキスト を使って CRITIC に何か気のきいた ことを言ってもよい。このプロトコルでは、CRITIC はその賛辞 (compliment) に返事をしない。しかし、ZOO が多くの賛辞を使うと、 CRITIC が新しい写しをより受け付けてくれるようになると一般に信じら れている。 TRANSCRIPT ZOO は CRITIC に評価対象の新しい写しがあることを通知する。写しの 名前(name) とそれに付け加えた文字数がこの要求のパラメータとして指 定される。写しのテキストは続いて送られる。 THANKS ZOO がまもなく接続を終了するという指示子である。 8.2. CRITIC の回答 SIGH ZOO が接続を確立すると、CRITIC は SIGH (ため息) とオプションの侮 辱の言葉(insult)で返答しなければならない。 IMPRESS_ME CRITC は ZOO が TRANSCRIPT 要求をしてきたら、IMPRESS_ME で返答し なければならない。 REJECT REJECT 0 写しを受け取ったとき、 CRITIC は REJECT と拒絶の理由を表すコード で返答しなければならない。拒絶コードの表は次節で提供される。コー ドが 0 のときは、CRITIC は任意のテキスト(text) を使って回答するこ とができる。CRITC は写しのテキスト全文を受け取ったり処理したりす る前に REJECT を送ることができる。 DONT_CALL_US_WE'LL_CALL_YOU CRITC は接続を終了する前にこのステートメントを発する。 Christey Informational [Page 14] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 GRUDGING_ACCEPTANCE ＊＊この回答は PAN のこのバージョンではサポートしない。＊＊ 無限猿プロトコルスィートワーキンググループ(WIMPS) は RJECT が利用 可能ならば、CRITIC がこの回答を利用することはまずないだろうという ことで合意した。CRITIC がどのように動作するかを完全には理解してい ない実装者に対する説明のためだけにこれは含められている。早晩、 CRITIC が(猿がやるのと同じ方法で)進化するということもあるだろう。 そのような知己が来るとしたら、WIMPS は PAN の次のバージョンにこの 回答をサポートすることを決定するかもしれない。 8.3. CRITIC の拒絶コードの表 コードの解説 ------------------------------------------------------------------- | 0 | <暗号化された回答があとに続く。下記参照> ------------------------------------------------------------------- | 1 | "車輪の再発明だ。" ------------------------------------------------------------------- | 2 | "売り物にならない。" ------------------------------------------------------------------- | 3 | "はあ？ まるで理解できない。" ------------------------------------------------------------------- | 4 | "アイディアの全体が無に帰されるということが20年も前からボンヤ | | リとしめされていることを忘れたね。" ------------------------------------------------------------------- | 5 | "提案の数により、あらゆる写しを受け入れられなかった。" ------------------------------------------------------------------- | 6 | "図表やグラフが十分でない。カラーは使わないのかね？" ------------------------------------------------------------------- | 7 | "気が乗らないので君に当たり散らすことにした。" ------------------------------------------------------------------- | 8 | "求めている範疇に入らない。" ------------------------------------------------------------------- | 9 | "あまりに独創性に欠ける" ------------------------------------------------------------------- |10 | "提案は締め切りに間に合わなかった。また来年いらっしゃい。" ------------------------------------------------------------------- CRITIC が拒絶コード 0 を使った場合、テキストの回答は、CRITIC が選択 した暗号化手法を使わなければならない。PAN プロトコルは ZOO がどのよ うにどの手法が使われるかを決定するかを規定しないので、ZOO はCRITIC の回答を理解することはできないだろう。 Christey Informational [Page 15] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 8.4. PAN を使った ZOO-to-CRITIC セッションの試行 以下は 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 ("売り物にならない。") SanDiego> THANKS NoBrainer> DONT_CALL_US_WE'LL_CALL_YOU 9. セキュリティの考察 動物の人道的な取り扱いの原則にしたがい、IMPS の設計は、CRITIC が SIMIAN に直接接触することとその感情を傷付けることを明確に禁じている。 BARD と CRITIC は両方とも根本的な非互換性と設計上の不備のために分離 されている。 IMPS の残りの部分に関するセキュリティの考察は、もともとのインターネッ トプロトコルに関するものと同様である。明確に、IMPS は過去の過ちから 学ぶことを拒否し、瞬きをすることもなく同じ間違いをのんきに繰り返す。 信用できないエンティティが IMPS ネットワークにアクセスできれば、ス プーフィングやサービス不能(DoS)攻撃はいくらでもある。あらゆる通信は 暗号化されないクリアテキストで行われるので、進歩的な仕事は盗まれる ことを仮定している。このことは、ネットワークが CRITIC 以外のエンティ ティを含むのでなければ明白な問題とはならない。IAMB-PENT メッセージ については、BARD の本性は BARD が転送された作品から借用することを許 すが、設計により BARD は公然とは作品を盗むことができない。 ZOO は世界中からの疑似 SIMIAN による搾取に対し開かれたままになるか もしれない。サードパーティがパケット毎にメッセージ ID を 1 ずつ増や したパケットによる SIMIAN の洪水を起こして ZOO と SIMIAN の間の交信 を妨害することができる。より憎むべきは、ある集団が個々の SIMIAN に 対して単一の STOP 要求を送ることにより KEEPER プロトコルを無効化で き、これにより ZOO を通じて重大なサービス不能(DoS)を引き起こすこと ができることだ。また、ある集団は CHIMP 要求を覗き見たり、例えば Christey Informational [Page 16] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 DEAD ステータスのような嘘の情報を送ったりして、まだ十分に機能してい る猿を ZOO に交換させようとさせることができる。 加えて、ZOO が SIMIAN の要求(特に FOOD, WATER, VETERINARIAN) を繰り 返し拒否すると、ZOO はその特定の SIMIAN に関して、意図せずにサービ ス不能(DoS) を起こしてしまうかもしれない。しかし、KEEPER と CHIMP の両方が、NORESPONSE または DEAD のステータスコードにより ZOO がい い具合いにこの条件を検出することを許す。 すべての BARD は勝ちがたい金銭的な問題と低い優先度に直面するので、 本質的にセキュアでない。これらは BARD が信頼に足る働きをするのを妨 げる。BARD の実装がこれらの障害に打ち勝つような希有な場合は、15分間 だけはうまくいき、すぐにセキュアでない状態に戻るだろう [14]。CRITIC が適当な PAN 回答により BARD の成功を減らすので、このことは BARD と CRITIC をつねに分離しておくべきであることのもう1つの理由である。 非常にわずかな人しかほとんどの CRITIC の実装に関心を持たないと予想 され、CRIRIC それ自身は本質的にセキュアでない。したがって、CRITIC に関してセキュリティは重要でない。あまりに多くの SIMIAN が同時に写 しを送信したら、CRITC はサービス不能(DoS)攻撃の犠牲者となるかもしれ ない。加えて、ある SIMIAN が別の SIMIAN を覗き見すること(これは剽窃 行為として参照される)により進歩的でない作品を送るかもしれない。 CRITC の回答もまた覗き見されることがある。しかし、PAN のバージョン 1 では唯一サポートする回答が REJECT なので、些細な問題だ。将来のバー ジョンにおいて、もし GRUDGING_ACCEPTANCE の回答が許されるようになっ たら、気をつけならない。最後に、写しは転送により失われるかも知れな いし、PAN はこれが起こるかどうかを ZOO が決める機構を提供しない。 IMPS の将来のバージョンはこの根本的な設計の問題に回答を出すのにより 適したものになるかもしれない。すなわち、もし進歩的な作品が転送時に 失われたら CRITIC はそれでもをそれをけなす(PAN)ことができるかという ことを。 最近発見されたパケットレベルの弱みの数によると、いくつかの実装は、 正しくないパディングまたは予約されたビットのある、誤った形式の IMPS パケットを処理するとき、特に振る舞いがよくないということはすでに出 された結論である [15] [16] [17]。 Christey Informational [Page 17] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 最後に、無限の時間の経過を越えて、猿が進化し、どうやって自分達の SIMIAN インターフェースを制御し失敗の要求を送り写しを作り送るかを発 見するという事実に関してセキュリティを考慮していない。これはすでに 発生する兆候がある [18]。 10. 謝辞 著者は、この文書のサイズを3倍にするような技術的なコメントをくれた Andre Frech と、シェイクスピアの文法に関して教えてくれた Kean Kaufmann と Amanda Vizedom と、宇宙全体の本質を明瞭にしてくれた Rohn Blake と、アクセントに関してウィリアム＝シェイクスピアと、数字 の16と、黄色に感謝する。 11. 参考文献 [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. (私信). "Good question! I never thought of that! I bet nobody else has, either. Please pass the french fries." [4] 著者は1956 年とこの文書の日付の間に出版されたテレビガイドのあ らゆる話題の参照を見つけることはできなかった。 [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. Christey Informational [Page 18] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 [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] 様々な USENET にポストされた .signature , circa 1994. 著者不詳 [13] "Recognizing Irony, or How Not to be Duped When Reading." Faye Halpern. 1998. http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm [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] 1956年からこの文書の日付までに出版されたテレビガイドのあらゆる 話題。 12. 著者の連絡先 SteQven M. Christey EMail: steqve@shore.net Christey Informational [Page 19] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000 13. 完全な著作権の表示 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. Christey Informational [Page 20]