As per Relevance of the word infinite, we have this rfc below:
Network Working Group S.
Request for Comments: 2795 MonkeySeeDoo, Inc
Category: Informational 1 April 2000
The Infinite Monkey Protocol Suite (IMPS
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo describes a protocol suite which supports an
number of monkeys that sit at an infinite number of typewriters
order to determine when they have either produced the entire works
William Shakespeare or a good television show. The suite
communications and control protocols for monkeys and
organizations that interact with them
Table of
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.
It has been posited that if an infinite number of monkeys sit at
infinite number of typewriters and randomly press keys, they
eventually produce the complete works of Shakespeare [1] [2]. But
such a feat is accomplished, how would anybody be able to know?
what if the monkey has flawlessly translated Shakespeare's works
Esperanto? How could one build a system that obtains these
while addressing the basic needs of monkeys, such as sleep and food
Nobody has addressed the practical implications of these
questions [3].
In addition, it would be a waste of resources if such a
effort only focused on Shakespeare. With an infinite number
monkeys at work, it is also equally likely that a monkey
produce a document that describes how to end world poverty,
disease, or most importantly, write a good situation comedy
television [4]. Such an environment would be ripe for
and, with the proper technical design, could be effectively
to "make the world a whole lot brighter" [5].
The Infinite Monkey Protocol Suite (IMPS) is an experimental set
protocols that specifies how monkey transcripts may be collected
transferred, and reviewed for either historical accuracy (in the
of Shakespearean works) or innovation (in the case of new works).
also provides a basic communications framework for performing
monkey maintenance
2. Objects in the
There are four primary entities that communicate within an
network. Groups of monkeys are physically located in Zone
Organizations (ZOOs). The ZOOs maintain the monkeys and
equipment, obtain transcripts from the monkeys' typewriters,
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
the communications interface between a monkey and its ZOO. It
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
resource requests to the ZOO using human language phrases,
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
Efficient Emulation Protocol for Ecosystem Resources (KEEPER)
interact with the SIMIAN
The ZOO obtains typewriter transcripts from the SIMIAN, which
responsible for converting the monkey's typed text into an
format if non-digital typewriters are used. The ZOO may then
the transcripts to one or more entities who review the transcript'
contents. IMPS defines two such reviewer protocols, although
could be added
For Shakespearean works, as well as any other classic literature
has already been published, the ZOO forwards the transcript to a
(Big Annex of Reference Documents). The BARD determines if
transcript matches one or more documents in its annex. The ZOO
the transcript to a BARD using the Inter-Annex Message
Protocol for Evaluating Neoclassical Transcripts (IAMB-PENT).
transcripts are considered Neoclassical because (a) they
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
transcript to a CRITIC (Collective Reviewer's Innovative
Integration Center). The CRITIC determines if a transcript
sufficiently innovative to be published. The ZOO uses the
for Assessment of Novelty (PAN) to communicate with the CRITIC.
process of using PAN to send a transcript to a CRITIC is
referred to as foreshadowing
A diagram of IMPS concepts is provided below. Non-technical
such as mid-level managers, marketing personnel, and liberal
majors are encouraged to skip the next two sections. The rest
this document assumes that senior management has already
reading
Christey Informational [Page 3]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
-+-+-+-+-+- CHIMP -+-+-+-+-+-
| SIMIAN/ | ----------> * *
| MONKEY | * ZOO *
| | <---------- * *
-+-+-+-+-+- KEEPER -+-+-+-+-+-
/ \
/ \
IAMB-PENT / \
/ \
V
-+-+-+-+-+- -+-+-+-+-+-
* * * *
* BARD * * CRITIC *
* * * *
-+-+-+-+-+- -+-+-+-+-+-
3. IMPS Packet
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
are 32 bit unsigned integers. For IMPS version 1.0, the Version
be 1. Reserved must be 0 and will always be 0 in future uses. It
included because every other protocol specification includes
"future use" reserved field which never, ever changes and
therefore a waste of bandwidth and memory. [6] [7] [8].
The Source and Destination are identifiers for the IMPS objects
are communicating. They are represented using Infinite TAGs (
next section).
The Data section contains data which is of arbitrary length
The Size field records the size of the entire packet using
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
byte
Christey Informational [Page 4]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
4. Infinite Threshold Accounting Gadget (I-TAG)
Each SIMIAN requires a unique identifier within IMPS. This
describes design considerations for the IMPS identifier, referred
as an Infinite Threshold Accounting Gadget (I-TAG). The I-TAG
represent numbers of any size
To uniquely identify each SIMIAN, a system is required that
capable of representing an infinite number of identifiers. The
of all integers can be used as a compact representation. However
all existing protocols inherently limit the number of
integers by specifying a maximum number of bytes to be used for
integer. This approach cannot work well in an IMPS network with
infinite number of monkeys to manage
Practically speaking, one could select a byte size which
represent an integer that is greater than the number of atoms in
known universe. There are several limitations to this approach
however: (a) it would needlessly exclude IMPS implementations
may utilize sub-atomic monkeys and/or multiple universes; (b)
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
short of infinity. Since any entity that fully implements IMPS
probably very, very good at handling infinite numbers, IMPS
ensure that it can represent them
Netstrings, i.e. strings which encode their own size,
considered. However, netstrings have not been accepted as
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
implementation [10]. While it solves the Y10K problem and does
to infinity, its ASCII representation wastes memory by a
greater than 8. While this may not seem important in an
that has enough resources to support an infinite number of monkeys
it is inelegant for the purpose of monkey identification. It is
CPU intensive to convert such a representation to a binary number (
least based on the author's implementation, which was written in
combination of LISP, Perl, and Java). The algorithm is
and could lead to incorrect implementations. Finally, the author
this document sort of forgot about that RFC until it was too late
include it properly, and was already emotionally attached to the I
TAG idea anyway. It should be noted, however, that if a monkey
typed this particular section and it was submitted to a CRITIC,
would probably receive a PAN rejection code signifying
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,
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
an arbitrary integer. META-SIZE specifies an upper limit on how
bits are used to represent SIZE
META-SIZE is an arbitrary length sequence of N '1' bits terminated
a '0' bit, i.e. it has the form
11111...1110
where N is the smallest number such that 2^N exceeds the number
bits required to represent the number of bytes that are necessary
store the ID (i.e., SIZE).
The SIZE is then encoded using N bits, ordered from the
significant bit to the least significant bit
Finally, the ID is encoded using SIZE bytes
This representation, while clunky, makes efficient use of memory
is scalable to infinity. For any number X which is less than 2^
(for any N), a maximum of (N + log(N) + log(log(N)))/8 bytes
necessary to represent X. The math could be slightly incorrect,
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
margin [11].
5. KEEPER
Following is a description of the Knowledgeable and
Emulation Protocol for Ecosystem Resources (KEEPER), which the
uses to communicate with the SIMIAN. The IMPS protocol number
KEEPER is 1.
KEEPER is a connectionless protocol. The ZOO sends a request to
SIMIAN using a single IMPS packet. The SIMIAN sends a response
to the ZOO with another IMPS packet. The data portion of the
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,
version is 1)
Type = the type of message being sent. '0' is a request; '1' is
Message ID = a unique identifier to distinguish different
Message Code = the specific message being
When a ZOO sends a KEEPER request, the SIMIAN must send a
response which uses the same Message ID as the original request
5.1 KEEPER Message Request Codes (ZOO-to-SIMIAN
CODE NAME
+-----------------------------------------------------------+
| 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
+-------------------------------------------------------------+
| 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
Below are the requirements for request and response codes
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
code. SIMIAN implementors must be careful when checking
heartbeat of very relaxed monkeys who practice
meditation or yoga, as they may appear DEAD even if they are
alive
3. A SIMIAN must respond to a STOP request with a NORESPONSE, ALIVE
DEAD, or GONE code. How a SIMIAN stops the monkey
implementation-specific. However, the SIMIAN should preserve
monkey's ALIVE status to protect the ZOO from being shut down
authorities or animal rights groups. If the monkey is present
the SIMIAN interface is unable to verify whether the monkey is
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
code, especially if there are deadlines. The only other
responses are REFUSE, ASLEEP, GONE, NORESPONSE, or DEAD.
protocol does not define what actions should be taken if a
responds with REFUSE, although a BRIBE_BANANA command may be added
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
CHIMP session to send the transcript to the ZOO
5.4 Example ZOO-to-SIMIAN Exchanges using
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
self-awareness and independence
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
The following exchange might take place early in the morning,
BoBo was being poorly maintained and was working at its
very late the night before
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
SanDiego>
BoBoSIM>
SanDiego>
6. CHIMP
Following is a description of the Cross-Habitat Idiomatic
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
replies back to the SIMIAN
6.1. SIMIAN Client
SEND <resource
The SIMIAN is requesting a specific resource. The
may be FOOD, WATER, MEDICINE, VETERINARIAN, or TECHNICIAN
The SIMIAN makes requests for FOOD or WATER by
the monkey's behavior and environment, e.g. its food dish.
requests MEDICINE or VETERINARIAN if it observes that
monkey's health is declining in any way, e.g. carpal
syndrome or sore buttocks. How the SIMIAN determines
is implementation-specific. In cases where the SIMIAN
may be malfunctioning, it may request a TECHNICIAN
REPLACE
The ZOO must replace an item that is used by the monkey
typing activities. The item to be replaced may be TYPEWRITER
PAPER, RIBBON, CHAIR, TABLE, or MONKEY
CLEAN
The SIMIAN is requesting that the ZOO must clean an item.
item may be CHAIR, TABLE, or MONKEY. How the ZOO cleans
item is implementation-specific. This command is
in the protocol because it has been theorized that if
infinite number of monkeys sit at an infinite number
typewriters, the smell would be unbearable [12]. If
theory is proven true, then CLEAN may become the most
command in the entire protocol suite
NOTIFY
The SIMIAN notifies the ZOO of the monkey's status. The
may be any status as defined in the KEEPER protocol
i.e. ASLEEP, GONE, DISTRACTED, NORESPONSE, ALIVE, or DEAD
TRANSCRIPT
The SIMIAN notifies the ZOO of a new transcript from the monkey
The number of characters in the transcript is specified in
size parameter
Christey Informational [Page 10]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
The SIMIAN is terminating the connection
6.2. ZOO Server
HELO
Upon initial connection, the ZOO must send a HELO reply
The ZOO will fulfill the SIMIAN's request
The ZOO will fulfill the SIMIAN's request at a later time
The ZOO refuses to fulfill the SIMIAN's request
The ZOO has received the full text of a transcript that has
submitted by the SIMIAN
6.3 Example SIMIAN-to-ZOO Session using
Assume a monkey BoBo with a SIMIAN interface named BoBoSIM, and a
named SanDiego. Once the BoBoSIM client has established a
to the SanDiego server, the following session might take place
SanDiego> HELO CHIMP version 1.0 4/1/2000
BoBoSIM> REPLACE
SanDiego>
BoBoSIM> TRANSCRIPT 87
SanDiego>
BoBoSIM> xvkxvn i hate Binky xFnk , feEL hungry and sIck
BoBoSIM> so so sad sDNfkodgv .,n., ,HELP MEEEEEEEEE cv.Cvn
SanDiego>
BoBoSIM> SEND
SanDiego>
BoBoSIM> SEND
SanDiego>
BoBoSIM> SEND
SanDiego>
BoBoSIM> SEND
Christey Informational [Page 11]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
SanDiego>
BoBoSIM> NOTIFY
SanDiego>
BoBoSIM> NOTIFY
SanDiego>
BoBoSIM> REPLACE
SanDiego>
7. IAMB-PENT
Following is a description of the Inter-Annex Message
Protocol for Evaluating Neoclassical Transcripts (IAMB-PENT), which
ZOO uses to send transcripts to a BARD. The IMPS protocol number
5.
IAMB-PENT is a connection-oriented protocol. A ZOO (the "client")
sends a transcript phrases to the BARD (the "server"),
evaluates the transcript and notifies the ZOO if the
matches all of a classical work or a portion thereof
7.1. ZOO Client
RECEIVETH <transcript name
The ZOO notifies the BARD of a new transcript to be evaluated
The name of the transcript is provided
ANON
The ZOO notifies the BARD that a transcript of the given size
to be provided soon. The text of the transcript is then sent
ABORTETH
The ZOO notifies the BARD that it is about to close
connection. The ZOO must specify a closing message. A2, A3,
A4, and A5 must be accented syllables. U3, U4, and U5 must
be accented
7.2 BARD
HARK
When the ZOO establishes a connection, the BARD must send a
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
When a ZOO uses a RECEIVETH command to specify a
transcript, the BARD must respond with a PRITHEE. A2, A3, A4,
and A5 must be accented syllables. U3, U4, and U5 must not
accented
REGRETTETH
If the BARD does not have the transcript in its Annex, it
the REGRETTETH command to notify the ZOO. A2, A3, A4, and A
must be accented syllables. U3, U4, and U5 must not
accented
ACCEPTETH
If the BARD has located the transcript in its Annex, it uses
ACCEPTETH command to notify the ZOO. A2, A3, A4, and A
must be accented syllables. U3, U4, and U5 must not
accented
7.3 Example ZOO-to-BARD Session using IAMB-
This is a sample IAMB-PENT session in which a ZOO (SanDiego) sends
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
SanDiego> ABORTETH Fate may one day bless my
8. PAN
Following is a description of the Protocol for Assessment of
(PAN). A ZOO uses PAN to send monkey transcripts for review by
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
response back to the ZOO
Christey Informational [Page 13]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
8.1. ZOO
COMPLIMENT
The ZOO may say something nice to the CRITIC using the
text. The CRITIC does not respond to the compliment within
protocol. However, it is generally believed that the CRITIC
more likely to accept a new transcript when a ZOO uses
compliments
TRANSCRIPT
The ZOO notifies the CRITIC of a new transcript for review
The name of the transcript, plus the number of characters,
specified as parameters to this request. The text of
transcript is then sent
This is an indicator that a ZOO is about to terminate
connection
8.2. CRITIC
SIGH
When the ZOO establishes a connection, the CRITIC must
with a SIGH and an optional insult
IMPRESS_
A CRITIC must respond with an IMPRESS_ME once a ZOO has made
TRANSCRIPT request
REJECT REJECT 0
When a transcript has been received, the CRITIC must
with a REJECT and a code that indicates the reason
rejection. A table of rejection codes is provided below.
the code is 0, the CRITIC may respond using free text. A
may send a REJECT before it has received or processed the
text of the transcript
DONT_CALL_US_WE'LL_CALL_
The CRITIC makes this statement before terminating
connection
Christey Informational [Page 14]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
GRUDGING_
THIS RESPONSE IS NOT SUPPORTED IN THIS VERSION OF PAN.
Working group for the Infinite Monkey Protocol Suite (WIMPS
agreed that it is highly unlikely that a CRITIC will ever
this response when a REJECT is available. It is only
as an explanation to implementors who do not fully
how CRITICs work. In time, it is possible that a CRITIC
evolve (in much the same way that a monkey might). Should
a time ever come, the WIMPS may decide to support this
in later versions of PAN
8.3. Table of CRITIC Reject
CODE
-------------------------------------------------------------------
| 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
| | ago that renders your whole idea null and void."
-------------------------------------------------------------------
| 5 | "Due to the number of submissions, we could not accept
| | 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
| | next year."
-------------------------------------------------------------------
If the CRITIC uses a reject code of 0, then the textual
must use an encryption scheme that is selected by the CRITIC
Since the PAN protocol does not specify how a ZOO may
what scheme is being used, the ZOO might not be able to
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
Below is a sample session from a ZOO (SanDiego) to a
(NoBrainer).
NoBrainer> SIGH Abandon hope all who enter
SanDiego> COMPLIMENT We love your work. Your words are
SanDiego> COMPLIMENT jewels and you are always correct
SanDiego> TRANSCRIPT RomeoAndJuliet.BoBo.763 251
NoBrainer> IMPRESS_
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
SanDiego> A pair of star-cross'd lovers take their life
NoBrainer> REJECT 2 ("This will never, ever sell.")
SanDiego>
NoBrainer> DONT_CALL_US_WE'LL_CALL_
9. Security
In accordance with the principles of the humane treatment
animals, the design of IMPS specifically prohibits the CRITIC
contacting the SIMIAN directly and hurting its feelings.
and CRITICs are also separated because of
incompatibilities and design flaws
The security considerations for the rest of IMPS are similar
those for the original Internet protocols. Specifically,
refuses to learn from the mistakes of the past and
repeats the same errors without batting an eye. Spoofing
denial of service attacks abound if untrusted entities gain
to an IMPS network. Since all transmissions occur in
without encryption, innovative works are subject to theft,
is not a significant problem unless the network contains
other than CRITICs. The open nature of BARDs with respect
IAMB-PENT messages allows a BARD to borrow heavily
transmitted works, but by design BARDs are incapable of
transcripts outright
The ZOO may be left open to exploitation by pseudo-SIMIANs
around the world. A third party could interrupt
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
STOP request to each SIMIAN, thus causing a massive denial
service throughout the ZOO. The party could also spoof a
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,
could cause a ZOO to attempt to replace a monkey that is
functioning properly
In addition, if a ZOO repeatedly rejects a SIMIAN's
(especially those for FOOD, WATER, and VETERINARIAN), then the
may inadvertently cause its own denial of service with respect
that particular SIMIAN. However, both KEEPER and CHIMP allow
ZOO to detect this condition in a timely fashion via
NORESPONSE or DEAD status codes
All BARDs are inherently insecure because they face
financial problems and low prioritization, which prevents
from working reliably. In the rare cases when a
implementation overcomes these obstacles, it is only
for 15 minutes, and reverts to being insecure
thereafter [14]. Since a CRITIC could significantly reduce
success of a BARD with an appropriate PAN response, this is
more reason why BARDs and CRITICs should always be kept
from each other
It is expected that very few people will care about
implementations of CRITIC, and CRITICs themselves are
insecure. Therefore, security is not a priority for CRITICs.
CRITIC may become the victim of a denial of service attack if
many SIMIANs submit transcripts at the same time. In addition
one SIMIAN may submit a non-innovative work by spoofing
SIMIAN (this is referred to as the Plagiarism Problem). A
response can also be spoofed, but since the only
supported in PAN version 1 is REJECT, this is of
consequence. Care must be taken in future versions if
GRUDGING_ACCEPTANCE response is allowed. Finally, a
may be lost in transmission, and PAN does not provide a
for a ZOO to determine if this has happened. Future versions
IMPS may be better suited to answer this fundamental
problem: if an innovative work is lost in transmission, can
CRITIC still PAN it
Based on the number of packet-level vulnerabilities discovered
recent years, it is a foregone conclusion that
implementations will behave extremely poorly when
malformed IMPS packets with incorrect padding or reserved
[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
fact that over the course of infinite time, monkeys may evolve
discover how to control their own SIMIAN interfaces and send
requests, or to compose and submit their own transcripts.
are indications that this may already be happening [18].
10.
The author wishes to thank Andre Frech for technical comments
tripled the size of this document, Kean Kaufmann and
Vizedom for lectures on Shakespearean grammar, Rohn Blake
clarifying the nature of the entire universe, William
for accents, the number 16, and the color yellow
11.
[1] The Famous Brett Watson, "The Mathematics of Monkeys
Shakespeare." http://www.nutters.org/monkeys.
[2] Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.
[3] K. Clark, Stark Mill Brewery, Manchester, NH, USA. Feb 18,
2000. (personal communication). "Good question! I never
of that! I bet nobody else has, either. Please pass the
fries."
[4] The author was unable to find a reference in any issue of
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
Relay", STD 55, RFC 2427, September 1998.
[9] Internet-Draft, bernstein-netstrings-06 (expired Work
Progress). D.J. Bernstein. Inclusion of this reference is
violation of RFC 2026 section 2.2.
[10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond",
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
Jokes That are Funny Because They're True and People Can't
Them for Centuries." P. Fermat. Circa 1630.
[12] .signature in various USENET postings, circa 1994.
unknown
[13] "Recognizing Irony, or How Not to be Duped When Reading."
Faye Halpern. 1998.
http://www.brown.edu/Student_Services/Writing_Center/halpern1.
[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
this document
12. Author's
SteQven M.
EMail: steqve@shore.
Christey Informational [Page 19]
RFC 2795 The Infinite Monkey Protocol Suite (IMPS) 1 April 2000
13. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Christey Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
