rfc2795.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

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