rfc2795.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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