doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc2795.txt b/doc/rfc/rfc2795.txt
new file mode 100644
index 0000000..187c5d3
--- /dev/null
+++ b/doc/rfc/rfc2795.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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.
+
+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
+
+
+
+Christey                     Informational                      [Page 1]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+    8.3 Table of CRITIC Reject Codes . . . . . . . . . . . . . . 15
+    8.4 Example ZOO-to-CRITIC Session using PAN  . . . . . . . . 16
+   9. Security Considerations  . . . . . . . . . . . . . . . . . 16
+   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . 18
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . 18
+   12. Author's Address  . . . . . . . . . . . . . . . . . . . . 19
+   13. Full Copyright Statement . . . . . . . . . . . . . . . . .20
+
+1. Introduction
+
+   It has been posited that if an infinite number of monkeys sit at an
+   infinite number of typewriters and randomly press keys, they will
+   eventually produce the complete works of Shakespeare [1] [2].  But if
+   such a feat is accomplished, how would anybody be able to know?  And
+   what if the monkey has flawlessly translated Shakespeare's works into
+   Esperanto?  How could one build a system that obtains these works
+   while addressing the basic needs of monkeys, such as sleep and food?
+   Nobody has addressed the practical implications of these important
+   questions [3].
+
+   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].
+
+   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.
+
+2. Objects in the Suite
+
+   There are four primary entities that communicate within an IMPS
+   network.  Groups of monkeys are physically located in Zone Operations
+   Organizations (ZOOs).  The ZOOs maintain the monkeys and their
+   equipment, obtain transcripts from the monkeys' typewriters, and
+   interact with other entities who evaluate the transcripts.
+
+   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
+
+
+
+
+Christey                     Informational                      [Page 2]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+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 Packet Structure
+
+   All IMPS protocols must utilize the following packet structure.
+
+    |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
+    |Version | Seq  # | Protocol # | Reserved  | Size  |
+    |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
+    |         Source        |      Destination         |
+    |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
+    |           Data                        | Padding  |
+    |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
+
+   The Version, Sequence Number, Protocol Number, and Reserved fields
+   are 32 bit unsigned integers.  For IMPS version 1.0, the Version must
+   be 1.  Reserved must be 0 and will always be 0 in future uses.  It is
+   included because every other protocol specification includes a
+   "future use" reserved field which never, ever changes and is
+   therefore a waste of bandwidth and memory. [6] [7] [8].
+
+   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.
+
+
+
+
+Christey                     Informational                      [Page 4]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+4. Infinite Threshold Accounting Gadget (I-TAG) Encoding
+
+   Each SIMIAN requires a unique identifier within IMPS.  This section
+   describes design considerations for the IMPS identifier, referred to
+   as an Infinite Threshold Accounting Gadget (I-TAG).  The I-TAG can
+   represent numbers of any size.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Christey                     Informational                      [Page 5]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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 [11].
+
+5. KEEPER Specification
+
+   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.
+
+   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:
+
+
+
+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, 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.
+
+5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN)
+
+    CODE    NAME       DESCRIPTION
+   +-----------------------------------------------------------+
+   | 0    | RESERVED | Reserved                                |
+   +-----------------------------------------------------------+
+   | 1    | STATUS   | Determine status of monkey              |
+   +-----------------------------------------------------------+
+   | 2    | HEARTBEAT| Check to see if monkey has a heartbeat  |
+   +-----------------------------------------------------------+
+   | 3    | WAKEUP   | Wake up monkey                          |
+   +-----------------------------------------------------------+
+   | 4    | TYPE     | Make sure monkey is typing              |
+   +-----------------------------------------------------------+
+   | 5    | FASTER   | Monkey must type faster                 |
+   +-----------------------------------------------------------+
+   | 6    |TRANSCRIPT| Send transcript                         |
+   +-----------------------------------------------------------+
+   | 7    | STOP     | Stop all monkey business                |
+   +-----------------------------------------------------------+
+   |8-512 | FUTURE   | Reserved for future use                 |
+   +-----------------------------------------------------------+
+   | 513+ | USER     | User defined                            |
+   +-----------------------------------------------------------+
+
+
+
+
+
+
+
+
+Christey                     Informational                      [Page 7]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+5.2 KEEPER Message Response Codes (SIMIAN-to-ZOO)
+
+    CODE    NAME       DESCRIPTION
+   +-------------------------------------------------------------+
+   | 0    | RESERVED | Reserved                                  |
+   +-------------------------------------------------------------+
+   | 1    | ASLEEP   | Status: Monkey is asleep                  |
+   +-------------------------------------------------------------+
+   | 2    | GONE     | Status: Monkey is not at typewriter       |
+   +-------------------------------------------------------------+
+   | 3    |DISTRACTED| Status: Monkey is distracted (not typing) |
+   +-------------------------------------------------------------+
+   | 4    |NORESPONSE| Status: Monkey is not responding          |
+   +-------------------------------------------------------------+
+   | 5    | ALIVE    | Status: Monkey is alive                   |
+   +-------------------------------------------------------------+
+   | 6    | DEAD     | Status: Monkey is dead                    |
+   +-------------------------------------------------------------+
+   | 7    | ACCEPT   | Monkey accepts request                    |
+   +-------------------------------------------------------------+
+   | 8    | REFUSE   | Monkey refuses request                    |
+   +-------------------------------------------------------------+
+   | 9-512| FUTURE   | Reserved for future use                   |
+   +-------------------------------------------------------------+
+   | 513+ | USER     | User defined                              |
+   +-------------------------------------------------------------+
+
+5.3 Requirements for KEEPER Request and Response Codes
+
+   Below are the requirements for request and response codes within
+   KEEPER.
+
+   1. A SIMIAN must respond to a STATUS request with an ALIVE, DEAD,
+   ASLEEP, GONE, DISTRACTED, or NORESPONSE code.
+
+   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.
+
+   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.
+
+
+
+Christey                     Informational                      [Page 8]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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.
+
+5.4 Example ZOO-to-SIMIAN Exchanges using KEEPER
+
+   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.
+
+   SanDiego> STATUS
+   BoBoSIM>  DISTRACTED
+   SanDiego> TYPE
+   BoBoSIM>  REFUSE
+   SanDiego> TYPE
+   BoBoSIM>  REFUSE
+   SanDiego> TYPE
+   BoBoSIM>  GONE
+
+   The following exchange might take place early in the morning, if
+   BoBo was being poorly maintained and was working at its typewriter
+   very late the night before.
+
+   SanDiego> WAKEUP
+   BoBoSIM>  NORESPONSE
+   SanDiego> WAKEUP
+   BoBoSIM>  NORESPONSE
+   SanDiego> WAKEUP
+   BoBoSIM>  NORESPONSE
+   SanDiego> HEARTBEAT
+   BoBoSIM>  DEAD
+   SanDiego> TRANSCRIPT
+
+6. CHIMP Specification
+
+   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.
+
+
+
+Christey                     Informational                      [Page 9]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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.
+
+6.1. SIMIAN Client Requests
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+Christey                     Informational                     [Page 10]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   BYE
+
+     The SIMIAN is terminating the connection.
+
+6.2. ZOO Server Responses
+
+   HELO <free text>
+
+     Upon initial connection, the ZOO must send a HELO reply.
+
+   ACCEPT
+
+     The ZOO will fulfill the SIMIAN's request.
+
+   DELAY
+
+     The ZOO will fulfill the SIMIAN's request at a later time.
+
+   REFUSE
+
+     The ZOO refuses to fulfill the SIMIAN's request.
+
+   RECEIVED
+
+     The ZOO has received the full text of a transcript that has been
+     submitted by the SIMIAN.
+
+6.3 Example SIMIAN-to-ZOO Session using CHIMP
+
+   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.
+
+      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 Specification
+
+   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.
+
+   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.
+
+7.1. ZOO Client Requests
+
+   RECEIVETH <transcript name>
+
+     The ZOO notifies the BARD of a new transcript to be evaluated.
+     The name of the transcript is provided.
+
+   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.
+
+   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.
+
+7.2 BARD Responses
+
+    HARK <U1> <A2> <U3> <A3> <U4> <A4> <U5> <A5>
+
+      When the ZOO establishes a connection, the BARD must send a HARK
+      command.  A2, A3, A4, and A5 must be accented syllables.  U1,
+      U2, U3, U4, and U5 must not be accented.
+
+
+
+
+
+Christey                     Informational                     [Page 12]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+    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.
+
+7.3 Example ZOO-to-BARD Session using IAMB-PENT
+
+   This is a sample IAMB-PENT session in which a ZOO (SanDiego) sends a
+   transcript to a BARD (William).
+
+     William> HARK now, what light through yonder window breaks?
+     SanDiego> RECEIVETH TRANSCRIPT SanDiego.BoBo.17
+     William> PRITHEE thy monkey's wisdom poureth forth!
+     SanDiego> ANON 96
+     SanDiego> I must be cruel, only to be kind.  Thus bad begins,
+               and worse remains in front.
+     William> REGRETTETH none hath writ thy words before
+     SanDiego> ABORTETH Fate may one day bless my zone
+
+8. PAN Specification
+
+   Following is a description of the Protocol for Assessment of Novelty
+   (PAN).  A ZOO uses PAN to send monkey transcripts for review by a
+   CRITIC.  The IMPS protocol number for PAN is 10 [13].
+
+   PAN 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.
+
+
+
+
+
+
+
+Christey                     Informational                     [Page 13]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+8.1. ZOO Requests
+
+   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.
+
+   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.
+
+   THANKS
+
+     This is an indicator that a ZOO is about to terminate the
+     connection.
+
+8.2. CRITIC Responses
+
+   SIGH <insult>
+
+     When the ZOO establishes a connection, the CRITIC must respond
+     with a SIGH and an optional insult.
+
+   IMPRESS_ME
+
+     A CRITIC must respond with an IMPRESS_ME once a ZOO has made a
+     TRANSCRIPT request.
+
+   REJECT <code> REJECT 0 <text>
+
+     When a transcript has been received, the CRITIC must respond
+     with a REJECT and a code that indicates the reason for
+     rejection.  A table of rejection codes is provided below.  When
+     the code is 0, the CRITIC may respond using free text.  A CRITIC
+     may send a REJECT before it has received or processed the full
+     text of the transcript.
+
+   DONT_CALL_US_WE'LL_CALL_YOU
+
+     The CRITIC makes this statement before terminating the
+     connection.
+
+
+
+
+Christey                     Informational                     [Page 14]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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.
+
+8.3. Table of CRITIC Reject Codes
+
+   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."
+   -------------------------------------------------------------------
+
+   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.
+
+
+
+
+Christey                     Informational                     [Page 15]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+8.4. Example ZOO-to-CRITIC Session using PAN
+
+   Below is a sample session from a ZOO (SanDiego) to a CRITIC
+   (NoBrainer).
+
+     NoBrainer> SIGH Abandon hope all who enter here
+     SanDiego> COMPLIMENT We love your work.  Your words are like
+     SanDiego> COMPLIMENT jewels and you are always correct.
+     SanDiego> TRANSCRIPT RomeoAndJuliet.BoBo.763 251
+     NoBrainer> IMPRESS_ME
+     SanDiego> Two households, both alike in dignity,
+     SanDiego> In fair Verona, where we lay our scene,
+     SanDiego> From ancient grudge break to new mutiny,
+     SanDiego> Where civil blood makes civil hands unclean.
+     SanDiego> From forth the fatal loins of these two foes
+     SanDiego> A pair of star-cross'd lovers take their life;
+     NoBrainer> REJECT 2    ("This will never, ever sell.")
+     SanDiego> THANKS
+     NoBrainer> DONT_CALL_US_WE'LL_CALL_YOU
+
+9. Security Considerations
+
+   In accordance with the principles of the humane treatment of
+   animals, the design of IMPS specifically prohibits the CRITIC from
+   contacting the SIMIAN directly and hurting its feelings.  BARDs
+   and CRITICs are also separated because of fundamental
+   incompatibilities and design flaws.
+
+   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.
+
+   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
+
+
+
+Christey                     Informational                     [Page 16]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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 [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.
+
+   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
+   [15] [16] [17].
+
+
+
+
+
+
+
+
+Christey                     Informational                     [Page 17]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+   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].
+
+10. Acknowledgements
+
+   The author wishes to thank Andre Frech for technical comments that
+   tripled the size of this document, Kean Kaufmann and Amanda
+   Vizedom for lectures on Shakespearean grammar, Rohn Blake for
+   clarifying the nature of the entire universe, William Shakespeare
+   for accents, the number 16, and the color yellow.
+
+11. References
+
+   [1]  The Famous Brett Watson, "The Mathematics of Monkeys and
+        Shakespeare."  http://www.nutters.org/monkeys.html
+
+   [2]  Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
+        http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html
+
+   [3]  K. Clark, Stark Mill Brewery, Manchester, NH, USA.  Feb 18,
+        2000.  (personal communication).  "Good question!  I never thought
+        of that!  I bet nobody else has, either.  Please pass the french
+        fries."
+
+   [4]  The author was unable to find a reference in any issue of TV
+        Guide published between 1956 and the date of this document.
+
+   [5]  "Dough Re Mi," The Brady Bunch.  Original air date January 14,
+        1972.
+
+   [6]  Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.
+
+   [7]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+        September 1981.
+
+   [8]  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
+        Relay", STD 55, RFC 2427, September 1998.
+
+   [9]  Internet-Draft, bernstein-netstrings-06 (expired Work in
+        Progress).  D.J. Bernstein.  Inclusion of this reference is a
+        violation of RFC 2026 section 2.2.
+
+   [10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC
+        2550, 1 April 1999.
+
+
+
+
+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] .signature in various USENET postings, circa 1994.  Author
+        unknown.
+
+   [13] "Recognizing Irony, or How Not to be Duped When Reading."
+        Faye Halpern.  1998.
+        http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm
+
+   [14] Andy Warhol.  Circa 1964.
+
+   [15] CERT Advisory CA-98-13.  CERT.  December 1998.
+        http://www.cert.org/advisories/
+
+   [16] CERT Advisory CA-97.28.  CERT.  December 1997.
+        http://www.cert.org/advisories/
+
+   [17] CERT Advisory CA-96.26.  CERT.  December 1996.
+        http://www.cert.org/advisories/
+
+   [18] All issues of TV Guide published between 1956 and the date of
+        this document.
+
+12. Author's Address
+
+   SteQven M. Christey
+   EMail: steqve@shore.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Christey                     Informational                     [Page 19]
+
+RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Christey                     Informational                     [Page 20]
+