(Translated by https://www.hiragana.jp/)
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]