RFC 2795

The Infinite Monkey Protocol Suite (IMPS)

📅 published April 2000, from ietf

RFC 2795: The Infinite Monkey Protocol Suite (IMPS) 🐒💖

  • Network Working Group 🎀
  • Request for Comments: 2795
  • Author: S. Christey, MonkeySeeDoo, Inc. 🧠
  • Category: Informational
  • Date: 1 April 2000 📅
  • Obsoletes/Updates: Nothing is listed here as obsoleted or updated. ✨

Status of This Memo 📝

okay so this memo is just here to share info with the Internet community 🌐 It is NOT a standard of any kind, so don't go treating it like one 🙅‍♀️ And distribution is unlimited, so share away bestie 💌

The Internet Society (2000) holds the copyright on this one, and all rights are reserved 📜

Abstract 🐵

this memo describes a protocol suite for an infinite number of monkeys, each sitting at their own infinite typewriter 🎹 The whole goal is figuring out when they've either typed out all of William Shakespeare's works or produced a good TV show 📺 The suite covers the communication and control protocols for the monkeys and for the organizations that work 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
 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's been posited that if an infinite number of monkeys sit at an infinite number of typewriters and randomly mash keys, they'll eventually produce the complete works of Shakespeare [1] [2] 😭 But like, if that actually happens, how would anybody even know? 🤔 And what if the monkey translated Shakespeare into Esperanto flawlessly? 🌍 How would you build a system that collects these works while also meeting the basic needs of monkeys, like sleep and food? 🍌 Nobody has tackled the practical side of these questions yet [3]. honestly iconic that nobody has checked 💀

Also, it would be such a waste if this massive effort only focused on Shakespeare 🙄 With an infinite number of monkeys working, it's just as likely that one of them writes a document explaining how to end world poverty, cure disease, or, most importantly, write a good sitcom for TV [4] 📺 That kind of environment would be ripe for innovation, and with the right technical design it could be used to "make the world a whole lot brighter" [5] 🌈

The Infinite Monkey Protocol Suite (IMPS) is an experimental set of protocols 🧪 It specifies how monkey transcripts get collected, transferred, and reviewed, either for historical accuracy (for the Shakespeare stuff) or for innovation (for brand new works) ✍️ It also gives a basic communications framework for normal monkey maintenance 🍓

2. Objects in the Suite 🧩

There are four main entities that talk to each other inside an IMPS network 💬 Groups of monkeys live physically in Zone Operations Organizations (ZOOs) 🦁 The ZOOs take care of the monkeys and their equipment, collect transcripts from the monkeys' typewriters, and work with the other entities that evaluate those transcripts 🫶

A SIMIAN (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node) is a device physically attached to the monkey 🎧 It's the communication interface between a monkey and its ZOO, basically a translator for the monkey 🗣️ It sends status reports and resource requests to the ZOO in human language phrases, and it responds to ZOO requests on the monkey's behalf 💅

The SIMIAN uses the Cross-Habitat Idiomatic Message Protocol (CHIMP) to talk to the ZOO 🐒 The ZOO uses the Knowledgeable and Efficient Emulation Protocol for Ecosystem Resources (KEEPER) to interact with the SIMIAN 🔐

The ZOO gets typewriter transcripts from the SIMIAN, which is responsible for turning the monkey's typed text into an electronic format if non-digital typewriters are being used 📄 After that, the ZOO may forward the transcripts to one or more entities that review their contents 🧐 IMPS defines two of these reviewer protocols, though others could be added later 🎀

For Shakespearean works, and any other classic literature that's already been published, the ZOO forwards the transcript to a BARD (Big Annex of Reference Documents) 📚 The BARD figures out whether 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) 💌 And the transcripts count as Neoclassical for two reasons: (a) they travel in electronic media instead of the original paper, and (b) the word "classical" doesn't start with the letter N 😂 I'm obsessed.

For new and potentially innovative works, the ZOO submits a transcript to a CRITIC (Collective Reviewer's Innovative Transcript Integration Center) ✨ The CRITIC decides whether a transcript is innovative enough to be published 🏆 The ZOO uses the Protocol for Assessment of Novelty (PAN) to talk to the CRITIC 🦋 Sending a transcript to a CRITIC through PAN is sometimes called foreshadowing 👀

Here's a diagram of the IMPS concepts 🗺️ Non-technical readers like mid-level managers, marketing people, and liberal arts majors are encouraged to skip the next two sections 🙈 The rest of this document assumes senior management has already stopped reading 💀

         -+-+-+-+-+-   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 it will always be 0 in future uses 🫠 It's included because every other protocol spec has a "future use" reserved field that never, ever changes, so it's basically a waste of bandwidth and memory 😭 [6] [7] [8]

The Source and Destination are identifiers for the IMPS objects that are communicating 🧑‍🤝‍🧑 They're represented using Infinite TAGs (see next section) 🏷️

The Data section holds data 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, so the packet gets rounded out to the next byte 🌸

4. Infinite Threshold Accounting Gadget (I-TAG) Encoding ✨

Okay bestie, every single SIMIAN needs its own unique identifier inside IMPS 🦋. This section is about the design thinking behind that IMPS identifier, which we call an Infinite Threshold Accounting Gadget (I-TAG). The I-TAG can represent numbers of any size 💖.

So to uniquely identify each SIMIAN, the system has to be able to represent an infinite number of identifiers 🧚. The set of all integers would be a cute compact way to do it 🍓. The problem is that every existing protocol caps integers by setting a maximum number of bytes for them, and that just doesn't work in an IMPS network with an infinite number of monkeys to manage 😭.

Practically speaking, you could pick a byte size that holds an integer bigger than the number of atoms in the known universe. But ngl there are a few problems with that: (a) it would needlessly exclude IMPS implementations that might use sub-atomic monkeys and/or multiple universes; (b) there is no consensus on how many atoms are in this universe; and (c) even though 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, which are strings that encode their own size, were considered too. But netstrings haven't been accepted as a standard, and they don't 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]. It solves the Y10K problem and does scale to infinity, but its ASCII representation wastes memory by a factor greater than 8 😩. Sure, that might not seem like a big deal in an environment with enough resources for an infinite number of monkeys, but it's inelegant for monkey identification. It's also CPU intensive to convert that 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 is clunky, but it 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:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version  | Type | Message ID    | Message Code  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version, Type, Message ID, and Message are all 16-bit integers. Here's the breakdown 🎀:

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                            |
+-----------------------------------------------------------+

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.
  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.

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 🐒

okay so the SIMIAN is the client side and it's literally always asking the ZOO for stuff 💅

SEND <resource>

The SIMIAN is requesting a specific resource. The resource may be FOOD, WATER, MEDICINE, VETERINARIAN, or TECHNICIAN. The SIMIAN asks for FOOD or WATER by reading the monkey's behavior and environment, like its food dish 🍓 It requests MEDICINE or VETERINARIAN if it notices the monkey's health is declining in any way, like carpal tunnel syndrome or sore buttocks 😭 How the SIMIAN figures out health is implementation-specific. And if the SIMIAN itself might be malfunctioning, it may request a TECHNICIAN. no shade, we all have off days 🫶

REPLACE <item>

The ZOO must replace an item that the monkey uses during typing activities. The item to be replaced may be TYPEWRITER, PAPER, RIBBON, CHAIR, TABLE, or MONKEY. this one is giving "the ZOO is on clean-up duty" 🧹

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 it is implementation-specific. This command is in the protocol because of a theory that if an infinite number of monkeys sat at an infinite number of typewriters, the smell would be unbearable [12]. ngl, if that theory turns out to be 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 defined in the KEEPER protocol, i.e. ASLEEP, GONE, DISTRACTED, NORESPONSE, ALIVE, or DEAD. main character energy for the monkey, honestly 🦋

TRANSCRIPT <size>

The SIMIAN notifies the ZOO of a new transcript from the monkey. The number of characters in the transcript is given in the size parameter. the monkey's writing era has officially begun ✍️

BYE

The SIMIAN is terminating the connection. bye bestie, see u next session 👋

6.2. ZOO Server Responses 🦁

the ZOO is the server and it's got the reply game down 🎀

HELO <free text>

Upon initial connection, the ZOO must send a HELO reply. first impressions matter, periodt ✨

ACCEPT

The ZOO will fulfill the SIMIAN's request. yesss queen 👑

DELAY

The ZOO will fulfill the SIMIAN's request at a later time. patience is a virtue, bestie 🌸

REFUSE

The ZOO refuses to fulfill the SIMIAN's request. not me saying "no" with a whole attitude 🙅‍♀️

RECEIVED

The ZOO has received the full text of a transcript that the SIMIAN submitted. the transcript has been delivered, we're so back 🦋

6.3 Example SIMIAN-to-ZOO Session using CHIMP 🍌

okay here's a session so u can see the vibe. we've got a monkey named BoBo with a SIMIAN interface called BoBoSIM, and a ZOO called SanDiego. once the BoBoSIM client has connected to the SanDiego server, a session might go like this:

   SanDiego> HELO CHIMP version 1.0 4/1/2000
   BoBoSIM> REPLACE PAPER
   SanDiego> ACCEPT
   BoBoSIM>  TRANSCRIPT 87
   SanDiego> ACCEPT
   BoBoSIM>  xvkxvn i hate Binky xFnk , feEL hungry and sIck sbNf
   BoBoSIM>  so so sad sDNfkodgv .,n.,  ,HELP MEEEEEEEEE cv.Cvn l
   SanDiego> RECEIVED
   BoBoSIM>  SEND FOOD
   SanDiego> ACCEPT
   BoBoSIM>  SEND MEDICINE
   SanDiego> DELAY
   BoBoSIM>  SEND VETERINARIAN
   SanDiego> REFUSE
   BoBoSIM>  SEND VETERINARIAN
   SanDiego> REFUSE
   BoBoSIM>  NOTIFY NORESPONSE
   SanDiego> ACCEPT
   BoBoSIM>  NOTIFY DEAD
   SanDiego> ACCEPT
   BoBoSIM>  REPLACE MONKEY
   SanDiego> ACCEPT

the "HELP MEEEEEEEEE" line 😭😭 bobo is literally in his feelings and the ZOO kept refusing the vet. that's a lot, sis 💀

7. IAMB-PENT Specification ✨

okay this section is about the Inter-Annex Message Broadcasting Protocol for Evaluating Neoclassical Transcripts (IAMB-PENT). it's how a ZOO sends transcripts to a BARD. the IMPS protocol number is 5.

IAMB-PENT is a connection-oriented protocol. a ZOO (the "client") sends transcript phrases to the BARD (the "server"), and the BARD checks the transcript and lets the ZOO know if it matches all of a classical work or a portion of one. the Shakespeare energy is unmatched 🎭🌹

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. bestie is about to drop a new piece 📜

ANON <size>

The ZOO notifies the BARD that a transcript of the given size is about to be provided. The text of the transcript is then sent. the anonymous drop, iykyk 🫣

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. the closing line has to be dramatic and in meter, no exceptions 🥀

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. the BARD opens with a whole greeting, slay 👑

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. ok the BARD is so extra and I'm obsessed 💜

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 let the ZOO know. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented. oof, not in the Annex 😭

ACCEPTETH <A2> <U3> <A3> <U4> <A4> <U5> <A5>

If the BARD has located the transcript in its Annex, it uses the ACCEPTETH command to let the ZOO know. A2, A3, A4, and A5 must be accented syllables. U3, U4, and U5 must not be accented. it's in the Annex, we're in the clear 🌈

7.3 Example ZOO-to-BARD Session using IAMB-PENT 🪶

this is a sample IAMB-PENT session where 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

William really said "none hath writ thy words before" and then got ghosted with a whole tragic goodbye 💀 the drama is immaculate.

8. PAN Specification 🎀

okay PAN is the Protocol for Assessment of Novelty. a ZOO uses it to send monkey transcripts over to a CRITIC for review. the IMPS protocol number for PAN is 10 [13].

PAN is a connection-oriented protocol. the ZOO (the "unwashed masses") sends a request to the CRITIC (the "all-powerful"), and the CRITIC sends a response back. the vibes are a LOT, but it's giving reality TV 📺

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. pls, compliment the critic, it's strategy 🫶

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 given as parameters to this request. The text of the transcript is then sent. here it comes, the moment of truth 😬

THANKS

This is an indicator that a ZOO is about to terminate the connection. thank u, next 👋

8.2. CRITIC Responses 🧐

SIGH <insult>

When the ZOO establishes a connection, the CRITIC must respond with a SIGH and an optional insult. the CRITIC is not here to be nice, it's giving judgmental 😤

IMPRESS_ME

A CRITIC must respond with an IMPRESS_ME once a ZOO has made a TRANSCRIPT request. literally the most demanding word ever 🙄

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. the CRITIC has the ability to say no before it even finishes reading, no cap 💀

DONT_CALL_US_WE'LL_CALL_YOU

The CRITIC makes this statement before terminating the connection. the ghosting is real and it's iconic 🥀

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. this one is not even in the building rn, it's a vibe for future monkeys only 🔮

8.3. Table of CRITIC Reject Codes 🚫

here's the whole reject-code lineup, no skipping 💅

   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 reject code 0, then the textual response must use an encryption scheme that the CRITIC selects. the PAN protocol doesn't say how a ZOO can figure out which scheme is being used, so the ZOO might not be able to understand the CRITIC's response. the mystery is the whole point 🕵️‍♀️

8.4. Example ZOO-to-CRITIC Session using PAN 🌸

here's 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

ok NoBrainer opened with an insult, got two compliments, then rejected Romeo and Juliet with "this will never, ever sell" 💀 the ghosting at the end was the cherry on top 🍒

9. Security Considerations 🔐

Okay bestie, so IMPS has a whole vibe about the humane treatment of animals 🙈 The design specifically bans the CRITIC from contacting the SIMIAN directly and hurting its feelings 🥺 BARDs and CRITICs are also kept apart, because they have fundamental incompatibilities and design flaws. Not a vibe. Just facts. 💅

The security stuff for the rest of IMPS is pretty much the same as the original Internet protocols, ngl. IMPS refuses to learn from the mistakes of the past and just repeats the same errors without even blinking 💀 Spoofing and denial of service attacks are everywhere if untrusted entities get into an IMPS network. Also, everything goes over the wire in cleartext with no encryption, so innovative works can get stolen. That's not a huge deal unless the network has entities other than CRITICs in it. The open nature of BARDs with respect to IAMB-PENT messages lets a BARD borrow heavily from transmitted works, but by design BARDs can't steal transcripts outright. Iconic restraint 👑

The ZOO might be open to exploitation by pseudo-SIMIANs from all over the world 🌍 A third party could interrupt communication between a ZOO and a SIMIAN by flooding the SIMIAN with packets, bumping the message ID by 1 for each packet. Even worse, the party could abuse the KEEPER protocol by sending a single STOP request to each SIMIAN, which causes a massive denial of service across the whole ZOO. Heinous behaviour 😤 The party could also spoof a CHIMP request, or send false info like a DEAD status, which could make a ZOO try to replace a monkey that is still functioning properly. Not okay!! 😭

Also, if a ZOO keeps rejecting a SIMIAN's requests (especially the ones for FOOD, WATER, and VETERINARIAN), the ZOO might accidentally cause its own denial of service for that particular SIMIAN 🙃 The good news is that both KEEPER and CHIMP let the ZOO catch this in a timely way through the NORESPONSE or DEAD status codes. Rescue energy ✨

All BARDs are inherently insecure, because they face insurmountable financial problems and low prioritization, which stops them from working reliably. In the rare case that a BARD implementation beats those obstacles, it only succeeds for 15 minutes and then goes right back to being insecure [14]. Since a CRITIC could seriously reduce a BARD's success with an appropriate PAN response, that's one more reason BARDs and CRITICs should always be kept separate. 🚧

It's expected that very few people will care about most implementations of CRITIC, and CRITICs are inherently insecure themselves. So security is not a priority for CRITICs 💀 A CRITIC may become the victim of a denial of service attack if too many SIMIANs submit transcripts at the same time. Also, one SIMIAN may submit a non-innovative work by spoofing another SIMIAN. This is called the Plagiarism Problem 😭🫵 A CRITIC response can be spoofed too, but since the only response supported in PAN version 1 is REJECT, it's of little consequence. Future versions need care if GRUDGING_ACCEPTANCE response is allowed. Finally, a transcript may get lost in transmission, and PAN doesn't give a ZOO any mechanism to figure out if that happened. Future versions of IMPS might 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 found in recent years, it's a foregone conclusion that some implementations will behave extremely poorly when processing malformed IMPS packets with incorrect padding or reserved bits [15] [16] [17]. Not surprising, sadly 💀

Finally, no security considerations are made for the fact that over the course of infinite time, monkeys may evolve and figure out how to control their own SIMIAN interfaces and send false requests, or compose and submit their own transcripts. There are indications that this may already be happening [18]. 👀🐒

10. Acknowledgements 🫶

The author would like 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 💛 Iconic list of thank-yous, honestly.

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. 🃏
  • [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

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸

Okay so, this document and translations of it can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can be made, copied, published, and distributed, in whole or in part, without restriction of any kind. The one condition is 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. The exceptions are when it's needed for developing Internet standards (then the procedures for copyrights defined in the Internet Standards process must be followed), or when it's required to translate it into languages other than English 🌍

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, bestie 💜

This document and the information in it 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. Thank you, Internet Society, you're literally the MVP 👑✨

📦 where this page comes from