Network Working Group S. Christey Request for Comments: 2795 MonkeySeeDoo, Inc. Category: Informational 1 April 2000 The Infinite Monkey Protocol Suite (IMPS) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Objects In The Suite . . . . . . . . . . . . . . . . . . . 2 3. IMPS Packet Structure . . . . . . . . . . . . . . . . . . 4 4. Infinite Threshold Accounting Gadget (I-TAG) Encoding . . 5 5. KEEPER Specification . . . . . . . . . . . . . . . . . . . 6 5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN) . . . . . . 7 5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO) . . . . . 8 5.3 Requirements for KEEPER Request and Response Codes . . . 8 5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER . . . . . . 9 6. CHIMP Specification . . . . . . . . . . . . . . . . . . . 9 6.1 SIMIAN Client Requests . . . . . . . . . . . . . . . . . 10 6.2 ZOO Server Responses . . . . . . . . . . . . . . . . . . 11 6.3 Example SIMIAN-to-ZOO Session using CHIMP . . . . . . . 11 7. IAMB-PENT SPECIFICATION . . . . . . . . . . . . . . . . . 12 7.1 ZOO Client Requests . . . . . . . . . . . . . . . . . . 12 7.2 BARD Responses . . . . . . . . . . . . . . . . . . . . . 12 7.3 Example ZOO-to-BARD Session using IAMB-PENT . . . . . . 13 8. PAN Specification . . . . . . . . . . . . . . . . . . . . 13 8.1 ZOO Requests . . . . . . . . . . . . . . . . . . . . . . 14 8.2 CRITIC Responses . . . . . . . . . . . . . . . . . . . . 14
8.3 Table of CRITIC Reject Codes . . . . . . . . . . . . . . 15 8.4 Example ZOO-to-CRITIC Session using PAN . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . 18 12. Author's Address . . . . . . . . . . . . . . . . . . . . 19 13. Full Copyright Statement . . . . . . . . . . . . . . . . .20 1] . 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 . 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 . 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" . 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.
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. 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. 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. 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. 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. 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.
-+-+-+-+-+- CHIMP -+-+-+-+-+- | SIMIAN/ | ----------> * * | MONKEY | * ZOO * | | <---------- * * -+-+-+-+-+- KEEPER -+-+-+-+-+- / \ / \ IAMB-PENT / \ PAN / \ V V -+-+-+-+-+- -+-+-+-+-+- * * * * * BARD * * CRITIC * * * * * -+-+-+-+-+- -+-+-+-+-+- 6]  . The Source and Destination are identifiers for the IMPS objects that are communicating. They are represented using Infinite TAGs (see next section). The Data section contains data which is of arbitrary length. The Size field records the size of the entire packet using Infinite TAG encoding. The end of the packet may contain extra padding, between 0 and 7 bits, to ensure that the size of packet is rounded out to the next byte.
9], "[Greater than] 999999999 bytes is bad." Well put. A scheme for identifying arbitrary dates was also considered for implementation . 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.
Since there is no acceptable representation for I-TAGs available, one is defined below. An I-TAG is divided into three sections: |-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+| | META-SIZE | SIZE | ID | |-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+| SIZE specifies how many bytes are used to represent the ID, which is an arbitrary integer. META-SIZE specifies an upper limit on how many bits are used to represent SIZE. META-SIZE is an arbitrary length sequence of N '1' bits terminated by a '0' bit, i.e. it has the form: 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). The SIZE is then encoded using N bits, ordered from the most significant bit to the least significant bit. Finally, the ID is encoded using SIZE bytes. 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. 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 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Message ID | Message Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version, Type, Message ID, and Message are all 16-bit integers. Version = the version of KEEPER being used (in this document, the version is 1) Type = the type of message being sent. '0' is a request; '1' is a response Message ID = a unique identifier to distinguish different messages Message Code = the specific message being sent When a ZOO sends a KEEPER request, the SIMIAN must send a KEEPER response which uses the same Message ID as the original request.
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. 5. A SIMIAN must respond to a WAKEUP request with ACCEPT, REFUSE, GONE, NORESPONSE, or DEAD. 6. A SIMIAN must respond to a TRANSCRIPT request by establishing a CHIMP session to send the transcript to the ZOO.
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. 12]. If this theory is proven true, then CLEAN may become the most critical command in the entire protocol suite. 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. 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.
BYE The SIMIAN is terminating the connection.
SanDiego> REFUSE BoBoSIM> NOTIFY NORESPONSE SanDiego> ACCEPT BoBoSIM> NOTIFY DEAD SanDiego> ACCEPT BoBoSIM> REPLACE MONKEY SanDiego> ACCEPT
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. 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. 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. 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.
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.
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. 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. 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 . 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. 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? 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   .
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 .  The Famous Brett Watson, "The Mathematics of Monkeys and Shakespeare." http://www.nutters.org/monkeys.html  Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory." http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html  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."  The author was unable to find a reference in any issue of TV Guide published between 1956 and the date of this document.  "Dough Re Mi," The Brady Bunch. Original air date January 14, 1972.  Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.  Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, September 1998.  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.  Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC 2550, 1 April 1999.
 "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.  .signature in various USENET postings, circa 1994. Author unknown.  "Recognizing Irony, or How Not to be Duped When Reading." Faye Halpern. 1998. http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm  Andy Warhol. Circa 1964.  CERT Advisory CA-98-13. CERT. December 1998. http://www.cert.org/advisories/  CERT Advisory CA-97.28. CERT. December 1997. http://www.cert.org/advisories/  CERT Advisory CA-96.26. CERT. December 1996. http://www.cert.org/advisories/  All issues of TV Guide published between 1956 and the date of this document.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.