RFC2795 日本語訳
2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. April 1 2000. (Format: TXT=42902 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Christey Request for Comments: 2795 MonkeySeeDoo, Inc. Category: Informational 1 April 2000
Christeyがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2795年のMonkeySeeDoo Inc.カテゴリ: 情報の2000年4月1日
The Infinite Monkey Protocol Suite (IMPS)
無限の猿プロトコル群(悪童)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 スイート. . . . . . . . . . . . . . . . . . . 2 3の物。 悪童パケットは.4 4を構造化します。 無限の敷居会計機械装置(不具合票)コード化. . 5 5。 キーパー仕様. . . . . . . . . . . . . . . . . . . 6 5.1キーパーメッセージ要求は、キーパー. . . . . . 9 6を使用することでキーパーのための.85.3の要件が要求する.75.2のキーパーメッセージ応答コード(猿から動物園)と例の動物園から猿が交換する応答コード. . . 8 5.4をコード化します(動物園から猿)。 チンパンジイ仕様. . . . . . . . . . . . . . . . . . . 9 6.1の猿のようなクライアントは、チンパンジイ. . . . . . . 11 7を使用することで.106.2の動物園サーバ応答. . . . . . . . . . . . . . . . . . 11 6.3例の猿から動物園へのセッションを要求します。 短長格で書かれた仕様. . . . . . . . . . . . . . . . . 12 7.1動物園クライアントは例の動物園から吟遊詩人へのセッション使用が.138に短長格で書いた.127.2の吟遊詩人応答. . . . . . . . . . . . . . . . . . . . . 12 7.3を要求します。 なべ仕様. . . . . . . . . . . . . . . . . . . . 13 8.1動物園要求. . . . . . . . . . . . . . . . . . . . . . 14 8.2評論家応答. . . . . . . . . . . . . . . . . . . . 14
Christey Informational [Page 1] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[1ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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
評論家廃棄物の8.3テーブルは、なべ. . . . . . . . 16 9を使用することで.158.4例の動物園から評論家へのセッションをコード化します。 セキュリティ問題. . . . . . . . . . . . . . . . . 16 10。 承認. . . . . . . . . . . . . . . . . . . . 18 11。 参照. . . . . . . . . . . . . . . . . . . . . . . 18 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 19 13。 完全な著作権宣言文… .20
1. Introduction
1. 序論
It has been posited that if an infinite number of monkeys sit at an infinite number of typewriters and randomly press keys, they will eventually produce the complete works of Shakespeare [1] [2]. But if such a feat is accomplished, how would anybody be able to know? And what if the monkey has flawlessly translated Shakespeare's works into Esperanto? How could one build a system that obtains these works while addressing the basic needs of monkeys, such as sleep and food? Nobody has addressed the practical implications of these important questions [3].
無限の数の猿が無限の数のタイプライタに座って、手当たりしだいにキーを押すと、結局シェイクスピア全集[1][2]を生産するのが置かれました。 しかし、そのような功績が優れているなら、だれもどうしたら知ることができますか? そして、猿がシェークスピアの作品をエスペラントに無傷に翻訳した場合、どうなるでしょうか? 人はどうしたら睡眠や食物などの猿の基本的ニーズを記述している間にこれらの作品を入手するシステムを構築できますか? だれもこれらの重要な質問[3]の実用的な含意を記述していません。
In addition, it would be a waste of resources if such a sizable effort only focused on Shakespeare. With an infinite number of monkeys at work, it is also equally likely that a monkey could produce a document that describes how to end world poverty, cure disease, or most importantly, write a good situation comedy for television [4]. Such an environment would be ripe for innovation and, with the proper technical design, could be effectively utilized to "make the world a whole lot brighter" [5].
さらに、そのようなかなり大きい努力がシェークスピアに焦点を合わせるだけであるなら、それはリソースの浪費でしょうに。 また、仕事における無限の数の猿と共に、猿は世界貧困を終わらせる方法を説明するドキュメントを等しく製作できそうです、療法病、または、最も重要に、テレビ[4]のために良い状況喜劇を書いてください。 適切なテクニカル・デザインで、そのような環境は、革新において熟して、事実上、「世界を非常に明るくしてください」という[5]に利用されるかもしれません。
The Infinite Monkey Protocol Suite (IMPS) is an experimental set of protocols that specifies how monkey transcripts may be collected, transferred, and reviewed for either historical accuracy (in the case of Shakespearean works) or innovation (in the case of new works). It also provides a basic communications framework for performing normal monkey maintenance.
Infinite MonkeyプロトコルSuite(IMPS)は猿転写が歴史的な精度(シェークスピアの作品の場合における)か革新(新しい作品の場合における)のどちらかのためにどう集められて、移されて、見直されるかもしれないかを指定する実験的なセットのプロトコルです。 また、それは通常の猿維持を実行するのに主文枠組みを提供します。
2. Objects in the Suite
2. スイートの物
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つの第一の実体があります。 猿のグループはZone Operations Organizations(ZOOs)に物理的に位置しています。 ZOOsは猿とそれらの設備を維持して、猿のタイプライタから転写を得て、転写を評価する他の実体と対話します。
A SIMIAN (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node) is a device that is physically attached to the monkey. It provides the communications interface between a monkey and its ZOO. It is
SIMIAN(準Integratedの、そして、Monkeyを連結しているAnthropomorphic Node)は物理的に猿に取り付けられる装置です。 それは猿とそのZOOとのコミュニケーションインタフェースを提供します。 それはそうです。
Christey Informational [Page 2] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[2ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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.
猿のための事実上翻訳者。 それは、人間の言語句を使用することで現状報告と資源要求をZOOに送って、猿を代表してZOO要求に応じます。
The SIMIAN uses the Cross-Habitat Idiomatic Message Protocol (CHIMP) to communicate with the ZOO. The ZOO uses the Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER) to interact with the SIMIAN.
SIMIANは、ZOOとコミュニケートするのに、Cross-生息地Idiomatic Messageプロトコル(CHIMP)を使用します。 Ecosystem Resources(KEEPER)がSIMIANと対話するのにZOOはKnowledgeableとEfficient Emulationプロトコルを使用します。
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からタイプライタ転写を得ます。(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(Reference Documentsの大きいAnnex)に転写を送ります。 BARDは、転写が別館の1通以上のドキュメントに合っているかどうか決定します。 ZOOは、Evaluating Neoclassical Transcripts(IAMB-PENT)にInter-別館Message Broadcastingプロトコルを使用することで転写をBARDに送ります。 (b) 転写は(a) 原始書類媒体の代わりに電子メディアでそれらを移すので、Neoclassicalであると考えられます、そして、「古典的である」という言葉は文字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(集合的なReviewerの革新的なTranscript Integrationセンター)に転写を提出します。 CRITICは、発行されるために転写が十分革新的であるかどうか決定します。 Novelty(PAN)のAssessmentがCRITICとコミュニケートするのにZOOはプロトコルを使用します。 転写をCRITICに送るのにPANを使用する過程は時々兆候と呼ばれます。
A diagram of IMPS concepts is provided below. Non-technical readers such as mid-level managers, marketing personnel, and liberal arts majors are encouraged to skip the next two sections. The rest of this document assumes that senior management has already stopped reading.
IMPS概念のダイヤグラムを以下に提供します。 中間レベルのマネージャや、マーケティング人員や、寛容な人文科学の専攻者などの非技術系の読者が次の2つのセクションをスキップするよう奨励されます。 このドキュメントの残りは、経営幹部が、読むのを既に止めたと仮定します。
Christey Informational [Page 3] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[3ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
-+-+-+-+-+- CHIMP -+-+-+-+-+-
| SIMIAN/ | ----------> * *
| MONKEY | * ZOO *
| | <---------- * *
-+-+-+-+-+- KEEPER -+-+-+-+-+-
/ \
/ \
IAMB-PENT / \ PAN
/ \
V V
-+-+-+-+-+- -+-+-+-+-+-
* * * *
* BARD * * CRITIC *
* * * *
-+-+-+-+-+- -+-+-+-+-+-
-+++++チンパンジイ+++++、-| 猿/| ---------->* * | 猿| * 動物園*| | <、-、-、-、-、-、-、-、-、-- * * -キーパー..短長格..書く..なべ..吟遊詩人..評論家
3. IMPS Packet Structure
3. 悪童パケット構造
All IMPS protocols must utilize the following packet structure.
すべてのIMPSプロトコルが以下のパケット構造を利用しなければなりません。
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
|Version | Seq # | Protocol # | Reserved | Size |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Source | Destination |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Data | Padding |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| |バージョン| Seq#| プロトコル#| 予約されます。| サイズ| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| | ソース| 目的地| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| | データ| 詰め物| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
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].
バージョン、Sequence Number、プロトコルNumber、および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物のための交信している識別子です。 それらは、Infinite TAGsを使用することで表されます(次のセクションを見てください)。
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分野は、Infinite 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ビットを含むかもしれません。
Christey Informational [Page 4] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[4ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
4. Infinite Threshold Accounting Gadget (I-TAG) Encoding
4. 無限の敷居会計機械装置(不具合票)コード化
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の中でユニークな識別子を必要とします。このセクションはInfinite Threshold Accounting Gadget(不具合票)と呼ばれたIMPS識別子のためにデザイン問題について説明します。 不具合票はどんなサイズの数も表すことができます。
To uniquely identify each SIMIAN, a system is required that is capable of representing an infinite number of identifiers. The set of all integers can be used as a compact representation. However, all existing protocols inherently limit the number of available integers by specifying a maximum number of bytes to be used for an integer. This approach cannot work well in an IMPS network with an infinite number of monkeys to manage.
唯一各SIMIANを特定するために、無限の数の識別子を表すことができるシステムが必要です。 コンパクトな表現としてすべての整数のセットを使用できます。 しかしながら、すべての既存のプロトコルが、本来整数に使用されるために最大数のバイトを指定することによって、有効な整数の数を制限します。 このアプローチは、管理するのに無限の数の猿と共にIMPSネットワークでうまくいくことができません。
Practically speaking, one could select a byte size which could represent an integer that is greater than the number of atoms in the known universe. There are several limitations to this approach, however: (a) it would needlessly exclude IMPS implementations that may utilize sub-atomic monkeys and/or multiple universes; (b) there is not a consensus as to how many atoms there are in this universe; and (c) while the number is extremely large, it still falls pitifully short of infinity. Since any entity that fully implements IMPS is probably very, very good at handling infinite numbers, IMPS must ensure that it can represent them.
実際に話すなら、人は既知の宇宙の中では、原子数より大きい整数を表すことができたバイトサイズを選択するかもしれません。 しかしながら、このアプローチへのいくつかの制限があります: (a) それは不必要にサブ原子の猿、そして/または、複数の宇宙を利用するかもしれないIMPS実現を除くでしょう。 (b) この宇宙の中にあるいくつの原子に関してコンセンサスがないか。 そして、(c) 数が非常に大きいのですが、それは無限よりまだ哀れに下回っています。 IMPSを完全に実行するどんな実体もたぶん無限の数を扱うのが非常に上手であるので、IMPSは、彼らを表すことができるのを確実にしなければなりません。
Netstrings, i.e. strings which encode their own size, were considered. However, netstrings have not been accepted as a standard, and they do not scale to infinity. As stated in [9], "[Greater than] 999999999 bytes is bad." Well put.
Netstrings(すなわち、それら自身のサイズをコード化するストリング)は考えられました。 しかしながら、netstringsは規格として認められていません、そして、彼らは無限で比例しません。 [9]に述べられているように「[大、]、999999999バイトが悪い、」 よく置きます。
A scheme for identifying arbitrary dates was also considered for implementation [10]. While it solves the Y10K problem and does scale to infinity, its ASCII representation wastes memory by a factor greater than 8. While this may not seem important in an environment that has enough resources to support an infinite number of monkeys, it is inelegant for the purpose of monkey identification. It is also CPU intensive to convert such a representation to a binary number (at least based on the author's implementation, which was written in a combination of LISP, Perl, and Java). The algorithm is complicated and could lead to incorrect implementations. Finally, the author of this document sort of forgot about that RFC until it was too late to include it properly, and was already emotionally attached to the I- TAG idea anyway. It should be noted, however, that if a monkey had typed this particular section and it was submitted to a CRITIC, it would probably receive a PAN rejection code signifying the reinvention of the wheel.
また、任意の期日を特定することの計画は実現[10]のために考えられました。 Y10K問題を解決して、無限で比例する間、要素より多くの8によるそのASCII表現廃棄物メモリです。 これは無限の数の猿を支持できるくらいのリソースを持っている環境で重要に見えないかもしれませんが、それは猿識別の目的のために優美ではありません。 また、それは2進の数(LISP、Perl、およびJavaの組み合わせで書かれた作者の実現に少なくとも基づいている)にそのような表現を変換するために徹底的なCPUです。 アルゴリズムは、複雑であり、不正確な実現につながるかもしれません。 最終的に、このドキュメントの作者は、適切にそれを含んでいるのが遅くなり過ぎるまでそのRFCをちょっと忘れて、既に感情的にとにかくI TAG考えに付けられました。 しかしながら、猿がこの特定のセクションをタイプして、CRITICにそれを提出するなら、たぶんホイールの再発明を意味するPAN拒絶コードを受け取ることに注意されるべきです。
Christey Informational [Page 5] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[5ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
Since there is no acceptable representation for I-TAGs available, one is defined below.
不具合票の利用可能などんな許容できる表現もないので、1つは以下で定義されます。
An I-TAG is divided into three sections:
不具合票は3つのセクションに分割されます:
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
| META-SIZE | SIZE | ID |
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
|-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+| | メタサイズ| サイズ| ID| |-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+|
SIZE specifies how many bytes are used to represent the ID, which is an arbitrary integer. META-SIZE specifies an upper limit on how many bits are used to represent SIZE.
SIZEは、いくつのバイトが任意の整数であるIDを表すのに使用されるかを指定します。 META-SIZEはいくつのビットがSIZEを表すのに使用されるかに関する上限を指定します。
META-SIZE is an arbitrary length sequence of N '1' bits terminated by a '0' bit, i.e. it has the form:
META-SIZEが'0'ビットに従って'1'ビットが終えたNの任意の長さの系列である、すなわち、それには、フォームがあります:
11111...1110
11111...1110
where N is the smallest number such that 2^N exceeds the number of bits required to represent the number of bytes that are necessary to store the ID (i.e., SIZE).
Nが最も少ない数であるところでは、2^Nがビットの数を超えているようなものがID(すなわち、SIZE)を格納するのに必要なバイト数を表すのが必要です。
The SIZE is then encoded using N bits, ordered from the most significant bit to the least significant bit.
そして、SIZEは、最も重要なビットから最下位ビットまで配置されたNビットを使用することでコード化されます。
Finally, the ID is encoded using SIZE bytes.
最終的に、IDは、SIZEバイトを使用することでコード化されます。
This representation, while clunky, makes efficient use of memory and is scalable to infinity. For any number X which is less than 2^N (for any N), a maximum of (N + log(N) + log(log(N)))/8 bytes is necessary to represent X. The math could be slightly incorrect, but it sounds right.
この表現は、不器用ですが、メモリの効率的な使用をして、無限でスケーラブルです。 N+は(N)+ログを登録します。2^N(どんなNのためのも)よりそれほど、そして、最大そうであるどんな数X、も((ログ(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].
顕著で、上品な小さいC機能はI TAG処理を実行するために書かれましたが、それには、このマージン[11]に含んでいるコードのあまりに多くの行があります。
5. KEEPER Specification
5. キーパー仕様
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.
以下に、Knowledgeableの記述とEcosystem Resources(KEEPER)のためのEfficient Emulationプロトコルがあります。(ZOOは、SIMIANとコミュニケートするのにEcosystem Resourcesを使用します)。 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に送り返します。 パケットのデータ部は以下のフォームのものです:
Christey Informational [Page 6] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[6ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Message ID | Message Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| タイプ| メッセージID| メッセージコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version, Type, Message ID, and Message are all 16-bit integers.
バージョン、Type、Message ID、およびMessageはすべて16ビットの整数です。
Version = the version of KEEPER being used (in this document, the
version is 1)
使用されるKEEPERのバージョン=バージョン(本書では、バージョンは1です)
Type = the type of message being sent. '0' is a request; '1' is a
response
タイプは送られるメッセージのタイプと等しいです。 '0'は要求です。 '1'は応答です。
Message ID = a unique identifier to distinguish different messages
メッセージIDは、異なったメッセージを区別するためにユニークな識別子と等しいです。
Message Code = the specific message being sent
メッセージ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はオリジナルの要求と同じMessage IDを使用するKEEPER応答を送らなければなりません。
5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN)
5.1 キーパーメッセージ要求コード(動物園から猿)
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 | 予約されます。| 予約されます。| +-----------------------------------------------------------+ | 1 | 状態| 猿の状態を決定してください。| +-----------------------------------------------------------+ | 2 | 鼓動| チェックして、猿で鼓動があるかどうか確認してください。| +-----------------------------------------------------------+ | 3 | WAKEUP| 猿を起こしてください。| +-----------------------------------------------------------+ | 4 | タイプ| 猿がタイプしているのを確実にしてください。| +-----------------------------------------------------------+ | 5 | より速い| 猿は、より速くタイプしなければなりません。| +-----------------------------------------------------------+ | 6 |転写| 転写を送ってください。| +-----------------------------------------------------------+ | 7 | 停止| すべてのいんちきを止めてください。| +-----------------------------------------------------------+ |8-512 | 未来| 今後の使用のために、予約されます。| +-----------------------------------------------------------+ | 513+ | ユーザ| 定義されたユーザ| +-----------------------------------------------------------+
Christey Informational [Page 7] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[7ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO)
5.2 キーパーメッセージ応答コード(猿から動物園)
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 | 予約されます。| 予約されます。| +-------------------------------------------------------------+ | 1 | 眠る| 状態: 猿は眠っています。| +-------------------------------------------------------------+ | 2 | 行きます。| 状態: 猿がタイプライタにいません。| +-------------------------------------------------------------+ | 3 |そらされます。| 状態: 猿はそらされます(タイプしません)。| +-------------------------------------------------------------+ | 4 |NORESPONSE| 状態: 猿は応じていません。| +-------------------------------------------------------------+ | 5 | 生きる| 状態: 猿は生きています。| +-------------------------------------------------------------+ | 6 | 死者| 状態: 猿は死んでいます。| +-------------------------------------------------------------+ | 7 | 受け入れてください。| 猿は要求を受け入れます。| +-------------------------------------------------------------+ | 8 | 廃物| 猿は要求を拒否します。| +-------------------------------------------------------------+ | 9-512| 未来| 今後の使用のために、予約されます。| +-------------------------------------------------------------+ | 513+ | ユーザ| 定義されたユーザ| +-------------------------------------------------------------+
5.3 Requirements for KEEPER Request and Response Codes
5.3 キーパー要求と応答コードのための要件
Below are the requirements for request and response codes within KEEPER.
以下に、KEEPERの中に要求と応答コードのための要件があります。
1. A SIMIAN must respond to a STATUS request with an ALIVE, DEAD, ASLEEP, GONE, DISTRACTED, or NORESPONSE code.
1. SIMIANはALIVE、DEAD、ASLEEP、GONE、DISTRACTED、またはNORESPONSEコードでSTATUS要求に応じなければなりません。
2. A SIMIAN must respond to a HEARTBEAT request with an ALIVE or DEAD code. SIMIAN implementors must be careful when checking the heartbeat of very relaxed monkeys who practice transcendental meditation or yoga, as they may appear DEAD even if they are still alive.
2. SIMIANはALIVEかDEADコードでHEARTBEAT要求に応じなければなりません。 トランセンデンタル・メディテーションかヨーガを訓練する非常に伸びやかな猿の鼓動をチェックするとき、SIMIAN作成者は慎重であるに違いありません、まだ生きてもDEADに見えるかもしれないように。
3. A SIMIAN must respond to a STOP request with a NORESPONSE, ALIVE, DEAD, or GONE code. How a SIMIAN stops the monkey is implementation-specific. However, the SIMIAN should preserve the monkey's ALIVE status to protect the ZOO from being shut down by authorities or animal rights groups. If the monkey is present but the SIMIAN interface is unable to verify whether the monkey is ALIVE or DEAD, then it must use a NORESPONSE.
3. SIMIANはNORESPONSE、ALIVE、DEAD、またはGONEコードでSTOP要求に応じなければなりません。 SIMIANがどう猿を止めるかは、実現特有です。 しかしながら、SIMIANは、当局か動物愛護団体によって止められるのからZOOを保護するために猿のALIVE状態を保持するはずです。 猿が存在していますが、SIMIANインタフェースが、猿がALIVEかそれともDEADであるかを確かめることができないなら、それはNORESPONSEを使用しなければなりません。
Christey Informational [Page 8] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[8ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
4. A SIMIAN should respond to a TYPE or FASTER request with an ACCEPT code, especially if there are deadlines. The only other allowed responses are REFUSE, ASLEEP, GONE, NORESPONSE, or DEAD. This protocol does not define what actions should be taken if a SIMIAN responds with REFUSE, although a BRIBE_BANANA command may be added in future versions.
4. 特に締め切りがあれば、SIMIANはACCEPTコードでTYPEかFASTER要求に応じるはずです。 他の唯一の許容応答が、REFUSE、ASLEEP、GONE、NORESPONSE、またはDEADです。 このプロトコルは、SIMIANがREFUSEと共に応じるならどんな行動が取られるべきであるかを定義しません、BRIBE_BANANAコマンドが将来のバージョンで加えられるかもしれませんが。
5. A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD.
5. SIMIANはACCEPT、REFUSE、GONE、NORESPONSE、またはDEADとのWAKEUP要求に応じなければなりません。
6. A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.
6. SIMIANは、転写をZOOに送るためにCHIMPセッションを確立することによって、TRANSCRIPT要求に応じなければなりません。
5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER
5.4 例の動物園から猿へのキーパーを使用する交換
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
SanDiego>状態BoBoSIM>がSanDiego>タイプBoBoSIM>廃物SanDiego>タイプBoBoSIM>廃物SanDiego>タイプBoBoSIM>をそらした、過ぎ去る。
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
SanDiegoのBoBoSIMの>の死んでいるSanDiego>>WAKEUP BoBoSIM>NORESPONSE SanDiego>WAKEUP BoBoSIM>NORESPONSE SanDiego>WAKEUP BoBoSIM>NORESPONSE SanDiego>鼓動転写
6. CHIMP Specification
6. チンパンジイ仕様
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.
以下に、Cross-生息地Idiomatic Messageプロトコル(CHIMP)の記述があります。(SIMIANは、ZOOとコミュニケートするのにプロトコルを使用します)。 CHIMPのIMPSプロトコル番号は2です。
Christey Informational [Page 9] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[9ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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
6.1. 猿のようなクライアント要求
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、議長(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が項目を掃除しなければならないよう要求しています。 項目は、議長(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に通知します。 転写における、キャラクタの数はサイズ・パラメータで指定されます。
Christey Informational [Page 10] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[10ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
BYE
さようなら
The SIMIAN is terminating the connection.
SIMIANは接続を終えています。
6.2. ZOO Server Responses
6.2. 動物園サーバ応答
HELO <free text>
HELOの<の無料のテキスト>。
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
6.3 例の猿から動物園へのチンパンジイを使用するセッション
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.
猿がSIMIANインタフェースがBoBoSIMと命名されて、ZOOがSanDiegoと命名されているBoBoであると仮定してください。 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>HELO CHIMPバージョン1.0 4/1/2000に、BoBoSIM>REPLACE PAPER SanDiego>ACCEPT BoBoSIM>TRANSCRIPT87SanDiego>ACCEPT BoBoSIM>xvkxvn iはBinky xFnkが嫌いであり、したがって、とても悲しいfeEL空腹、そして、sIck sbNf BoBoSIMの>はsDNfkodgvです; n.、ヘルプ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
Christeyの情報[11ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
SanDiego> REFUSE
BoBoSIM> NOTIFY NORESPONSE
SanDiego> ACCEPT
BoBoSIM> NOTIFY DEAD
SanDiego> ACCEPT
BoBoSIM> REPLACE MONKEY
SanDiego> ACCEPT
受け入れる>が>がBoBoSIM>を受け入れるように死んでいるSanDiego>に通知するBoBoSIMにNORESPONSE SanDiego>に通知するSanDiego>廃物BoBoSIMが>が受け入れる猿SanDiegoを取り替えます。
7. IAMB-PENT Specification
7. 短長格で書かれた仕様
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に送るのに使用するEvaluating Neoclassical Transcripts(IAMB-PENT)のためのInter-別館Message Broadcastingプロトコルの記述があります。 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
7.1. 動物園クライアント要求
RECEIVETH <transcript name>
RECEIVETH<転写名前>。
The ZOO notifies the BARD of a new transcript to be evaluated.
The name of the transcript is provided.
ZOOは、新しい転写のBARDが評価されるように通知します。 転写の名前を提供します。
ANON <size>
やがて、<サイズ>。
The ZOO notifies the BARD that a transcript of the given size is
to be provided soon. The text of the transcript is then sent.
ZOOは、与えられたサイズの転写がすぐ提供されることであるようにBARDに通知します。 そして、転写のテキストを送ります。
ABORTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
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が接続を終えようとしているように通知します。 ZOOは終わりのメッセージを指定しなければなりません。 A2、A3、A4、およびA5はアクセントのある音節であるに違いありません。 U3、U4、およびU5にアクセントをつけてはいけません。
7.2 BARD Responses
7.2 吟遊詩人応答
HARK <U1> <A2> <U3> <A3> <U4> <A4> <U5> <A5>
命令、<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にアクセントをつけてはいけません。
Christey Informational [Page 12] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[12ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
PRITHEE <A2> <U3> <A3> <U4> <A4> <U5> <A5>
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>
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がAnnexに転写を持っていないなら、それはZOOに通知するREGRETTETHコマンドを使用します。 A2、A3、A4、およびA5はアクセントのある音節であるに違いありません。 U3、U4、およびU5にアクセントをつけてはいけません。
ACCEPTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>
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がAnnexで転写の場所を見つけたなら、それはZOOに通知するACCEPTETHコマンドを使用します。 A2、A3、A4、およびA5はアクセントのある音節であるに違いありません。 U3、U4、およびU5にアクセントをつけてはいけません。
7.3 Example ZOO-to-BARD Session using IAMB-PENT
7.3 例の動物園から吟遊詩人への使用が短長格で書いたセッション
This is a sample IAMB-PENT session in which a ZOO (SanDiego) sends a transcript to a BARD (William).
これはZOO(SanDiego)がBARD(ウィリアム)に転写を送るサンプル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
現在のウィリアム>HARK、向こうの窓を通したどんな光が壊れますか? あなたの猿の知恵が先へpourethするSanDiego>RECEIVETH TRANSCRIPT SanDiego.BoBo.17ウィリアム>PRITHEE! SanDiego>ANON96SanDiego>Iは残酷であるに違いありませんが、親切です。 その結果、悪い、始まって、前部によりひどく残っています。 ウィリアム>REGRETTETH、なにも、SanDiego>ABORTETH Fateの前のあなたの言葉がある日そうするかもしれないhath令状は私のゾーンを祝福します。
8. PAN Specification
8. なべ仕様
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].
以下に、Novelty(PAN)のAssessmentのためのプロトコルの記述があります。 ZOOは、CRITICによるレビューのために猿転写を送るのにPANを使用します。 PANのIMPSプロトコル番号は10[13]です。
PAN is a connection-oriented protocol. A ZOO (the "unwashed masses") sends a request to the CRITIC (the "all-powerful"), which sends a response back to the ZOO.
PANは接続指向のプロトコルです。 ZOO(「汚い大衆」)はCRITIC(「全能」)に要求を送ります。(CRITICは応答をZOOに送り返します)。
Christey Informational [Page 13] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[13ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
8.1. ZOO Requests
8.1. 動物園要求
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
8.2. 評論家応答
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はインプレス_MEと共に応じなければなりません。
REJECT <code> REJECT 0 <text>
<コード>廃棄物0<テキスト>を拒絶してください。
When a transcript has been received, the CRITIC must respond
with a REJECT and a code that indicates the reason for
rejection. A table of rejection codes is provided below. When
the code is 0, the CRITIC may respond using free text. A CRITIC
may send a REJECT before it has received or processed the full
text of the transcript.
転写を受けたとき、CRITICは不合格理由を示すREJECTとコードで応じなければなりません。 拒絶コードのテーブルを以下に提供します。 コードが0であるときに、CRITICは、無料のテキストを使用することで応じるかもしれません。 転写の全文を受けるか、または処理する前にCRITICはREJECTを送るかもしれません。
DONT_CALL_US_WE'LL_CALL_YOU
ドント_が、_私たちがそうするつもりである米国_を_電話すると呼ぶ、_あなた
The CRITIC makes this statement before terminating the
connection.
接続を終える前に、CRITICはこの声明を出します。
Christey Informational [Page 14] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[14ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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.
この応答はなべのこのバージョンで支持されません。 Infinite MonkeyプロトコルSuite(WIMPS)のためのWorkingグループは、REJECTが利用可能であるときに、CRITICがこの応答を使用するのが、非常にありそうもないのに同意しました。 だれが、CRITICsがどのように働いているかを完全に理解しているというわけではないか説明として作成者に含められているだけです。 時間内に、CRITICが発展するのは(猿がそうするかもしれない似たり寄ったりの方法で)、可能です。 今までに来てください、WIMPSが、PANの後のバージョンにおけるこの応答を支持すると決めてもよいそのような時代にそうするべきです。
8.3. Table of CRITIC Reject Codes
8.3. 評論家廃棄物コードのテーブル
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によって選択される暗号化計画を使用しなければなりません。 ZOOが、どんな計画が使用されているかをどう決定するかもしれないかをPANプロトコルが指定しないので、ZOOはCRITICの応答を理解できないかもしれません。
Christey Informational [Page 15] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[15ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
8.4. Example ZOO-to-CRITIC Session using PAN
8.4. 例の動物園から評論家へのセッション使用なべ
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
NoBrainer>SIGH Abandonは、SanDiego>COMPLIMENT Weをここに入れるすべてがあなたの仕事がとても好きであることを望んでいます。 あなたの言葉はSanDiego>COMPLIMENT宝石に似ています、そして、あなたはいつも正しいです。 SanDiego>TRANSCRIPT RomeoAndJuliet.BoBo.763 251人のNoBrainer>インプレス_ME SanDiego>Two家庭、威厳でともに似ています、SanDiegoの>のInの公正なベロナ、新しい兵士の反乱へのSanDiegoの>のFromの古代の恨みの中断、SanDiegoの>のWhereの民間血液で民間手はきたなくなります。そこでは、私たちが場面を横たえます。 SanDiego>From、先へ、これらの2敵のSanDiego>A組の星十字d恋人の致命的な腰は彼らの命を取ります。 ありがとうございます、NoBrainer>ドント_CALL_米国_WEがそうするNoBrainer>REJECT2(「これは決して売れないでしょう」。)SanDiego>、_CALL_、あなた
9. Security Considerations
9. セキュリティ問題
In accordance with the principles of the humane treatment of animals, the design of IMPS specifically prohibits the CRITIC from contacting the SIMIAN directly and hurting its feelings. BARDs and CRITICs are also separated because of fundamental incompatibilities and design flaws.
動物の人間味がある処理の原則によると、IMPSのデザインは直接SIMIANに連絡して、気持ちを傷つけるのからCRITICを明確に禁じます。 また、BARDsとCRITICsは基本的な両立し難いことと設計上の欠陥のために切り離されます。
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ネットワークへのアクセスを得るなら、スプーフィングとサービス不能攻撃は富みます。 すべてのトランスミッションがcleartextに暗号化なしで起こるので、革新的な作品は窃盗を受けることがあります。(ネットワークがCRITICs以外の実体を含んでいない場合、それは、重大な問題ではありません)。 BARDはIAMB-PENTメッセージに関するBARDsの分かりやすい性格で伝えられた作品から大いに借りることができますが、故意に、BARDsは転写を完全に盗むことができません。
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
ZOOは疑似SIMIANsによって世界中から開発に開かれていた状態で外されるかもしれません。 第三者はパケットでSIMIANをあふれさせることによって、ZOOとSIMIANとのコミュニケーションを中断できるでしょう、メッセージIDを各パケットあたり1つ増加して。 より非道にも、パーティーはただ一つのSTOP要求を各SIMIANに送ることによって、KEEPERプロトコルを利用できるでしょう、その結果、ZOO中で大規模なサービスの否定を引き起こします。 また、パーティーはCHIMPをだますことができました。
Christey Informational [Page 16] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[16ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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.
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の両方で、ZOOはNORESPONSEか直ちにDEADステータスコードでこの状態を検出できます。
All BARDs are inherently insecure because they face insurmountable financial problems and low prioritization, which prevents them from working reliably. In the rare cases when a BARD implementation overcomes these obstacles, it is only successful for 15 minutes, and reverts to being insecure immediately thereafter [14]. Since a CRITIC could significantly reduce the success of a BARD with an appropriate PAN response, this is one more reason why BARDs and CRITICs should always be kept separate from each other.
彼らが打ち勝ちがたい経済問題と低い優先順位づけ(それらが確かに働いているのを防ぐ)に直面しているので、すべてのBARDsが本来不安定です。 BARD実現がこれらの障害を克服するときのまれなケースでは、それは、単に15分間成功していて、その後すぐに不安定に[14]を振り向けます。 適切なPAN応答に従ってCRITICがBARDの成功をかなり減少させることができたとき、これはBARDsとCRITICsがいつも互いから別々に保たれるべきであるもうひとつの理由です。
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のほとんどの実現を心配しないと予想されて、CRITICs自身は本来不安定です。 したがって、セキュリティはCRITICsのための優先ではありません。 あまりに多くのSIMIANsが同時に転写を提出するなら、CRITICはサービス不能攻撃の犠牲者になるかもしれません。 さらに、1SIMIANが、別のSIMIANをだますことによって、非革新的な仕事を提出するかもしれません(これはPlagiarism Problemと呼ばれます)。 また、CRITIC応答をだますことができますが、PANバージョン1で支持された唯一の応答がREJECTであるので、これは小さい結果のものです。 GRUDGING_ACCEPTANCE応答が許容されているなら、将来のバージョンで注意しなければなりません。 最終的に、転写はトランスミッションで失われるかもしれません、そして、ZOOが、これが起こったかどうか決定するように、PANはメカニズムを提供しません。 IMPSの将来のバージョンはこの基本的な設計上の問題に答えるために合うほうがよいです: 革新的な仕事はトランスミッションで失われていて、缶のa 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]を予約しました。
Christey Informational [Page 17] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[17ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
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
10. 承認
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.
作者はシェークスピアの文法に関する講演のためにこのドキュメント、キーン・コフマン、およびアマンダVizedomのサイズを3倍にした技術的なコメント、宇宙全体の自然をはっきりさせるためのレーン・ブレーク、アクセントのためのウィリアム・シェイクスピア、No.16、および色の黄色についてアンドレFrechに感謝したがっています。
11. References
11. 参照
[1] The Famous Brett Watson, "The Mathematics of Monkeys and
Shakespeare." http://www.nutters.org/monkeys.html
[1] 有名なブレット・ワトソン、「猿とシェークスピアの数学」、 http://www.nutters.org/monkeys.html
[2] Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html
[2] Math博士。 「シェークスピアをタイプする猿:」 「無限理論」 http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html
[3] K. Clark, Stark Mill Brewery, Manchester, NH, USA. Feb 18,
2000. (personal communication). "Good question! I never thought
of that! I bet nobody else has, either. Please pass the french
fries."
[3] K.クラーク、スターク工場Brewery、マンチェスター(ニューハンプシャー)、米国。 2000年2月18日。 (個人的なコミュニケーション。) 「良い質問!」 私はそれを決して考えませんでした! 私は、他の誰もが持っていないのを賭けます。 「フライドポテトを取ってください。」
[4] The author was unable to find a reference in any issue of TV
Guide published between 1956 and the date of this document.
[4] 作者は、テレビのどんな問題でも参照が1956の間で発表されたガイドとこのドキュメントの日付であることがわかることができませんでした。
[5] "Dough Re Mi," The Brady Bunch. Original air date January 14,
1972.
[5] 「パン生地reミ」、ブレイディ・バンチ。 1972年1月14日の元の空気期日。
[6] Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.
[6] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[8] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
Relay", STD 55, RFC 2427, September 1998.
[8] ブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」STD55、1998年9月のRFC2427。
[9] Internet-Draft, bernstein-netstrings-06 (expired Work in
Progress). D.J. Bernstein. Inclusion of this reference is a
violation of RFC 2026 section 2.2.
[9] インターネット草稿、bernstein-netstrings-06(ProgressにWorkを吐き出します)。 D.J.バーンスタイン。 この参照の包含はRFC2026部2.2の違反です。
[10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC
2550, 1 April 1999.
[10] グラスマン、S.、Manasse、M.、J.ムガール人、および「Y10Kと以遠」、RFC2550、1999年4月1日。
Christey Informational [Page 18] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[18ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
[11] "My Last Theorem: A Prankster's Guide to Ageless Mathematical
Jokes That are Funny Because They're True and People Can't Prove
Them for Centuries." P. Fermat. Circa 1630.
[11]、「私の最後の定理:」 「Ageless Mathematical Jokes ThatへのPranksterのガイドはFunny Because Theyが何世紀ものProve Themではなく、TrueとPeople Canであるということです。」 P。 フェルマー。 1630年頃に。
[12] .signature in various USENET postings, circa 1994. Author
unknown.
[12] 1994年頃の様々なUSENET任命における.signature。 未知を書いてください。
[13] "Recognizing Irony, or How Not to be Duped When Reading."
Faye Halpern. 1998.
http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm
[13] 「Irony、またはHow NotがDuped When Readingであると認めます。」 フェイ・アルペルン。 1998. http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm
[14] Andy Warhol. Circa 1964.
[14] アンディ・ウォーホル。 1964年頃に。
[15] CERT Advisory CA-98-13. CERT. December 1998.
http://www.cert.org/advisories/
[15]CERT勧告、カリフォルニア-98-13。 本命。 12月1998日の http://www.cert.org/advisories/
[16] CERT Advisory CA-97.28. CERT. December 1997.
http://www.cert.org/advisories/
[16] CERT勧告カリフォルニア-97.28。 本命。 12月1997日の http://www.cert.org/advisories/
[17] CERT Advisory CA-96.26. CERT. December 1996.
http://www.cert.org/advisories/
[17] CERT勧告カリフォルニア-96.26。 本命。 12月1996日の http://www.cert.org/advisories/
[18] All issues of TV Guide published between 1956 and the date of
this document.
[18] 1956の間で発行されたテレビのガイドのすべての問題とこのドキュメントの日付。
12. Author's Address
12. 作者のアドレス
SteQven M. Christey EMail: steqve@shore.net
SteQven M.Christeyはメールします: steqve@shore.net
Christey Informational [Page 19] RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
Christeyの情報[19ページ]のRFC2795無限の猿プロトコル群(悪童)2000年4月1日
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Christey Informational [Page 20]
Christey情報です。[20ページ]
一覧
スポンサーリンク
