rfc2795.txt

RFC 的详细文档！

   THANKS

     This is an indicator that a ZOO is about to terminate the
     connection.

8.2. CRITIC Responses

   SIGH <insult>

     When the ZOO establishes a connection, the CRITIC must respond
     with a SIGH and an optional insult.

   IMPRESS_ME

     A CRITIC must respond with an IMPRESS_ME once a ZOO has made a
     TRANSCRIPT request.

   REJECT <code> REJECT 0 <text>

     When a transcript has been received, the CRITIC must respond
     with a REJECT and a code that indicates the reason for
     rejection.  A table of rejection codes is provided below.  When
     the code is 0, the CRITIC may respond using free text.  A CRITIC
     may send a REJECT before it has received or processed the full
     text of the transcript.

   DONT_CALL_US_WE'LL_CALL_YOU

     The CRITIC makes this statement before terminating the
     connection.




Christey                     Informational                     [Page 14]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


   GRUDGING_ACCEPTANCE

     THIS RESPONSE IS NOT SUPPORTED IN THIS VERSION OF PAN.  The
     Working group for the Infinite Monkey Protocol Suite (WIMPS)
     agreed that it is highly unlikely that a CRITIC will ever use
     this response when a REJECT is available.  It is only included
     as an explanation to implementors who do not fully understand
     how CRITICs work.  In time, it is possible that a CRITIC may
     evolve (in much the same way that a monkey might).  Should such
     a time ever come, the WIMPS may decide to support this response
     in later versions of PAN.

8.3. Table of CRITIC Reject Codes

   CODE  DESCRIPTION
   -------------------------------------------------------------------
   | 0 | <Encrypted response following; see below>
   -------------------------------------------------------------------
   | 1 | "You're reinventing the wheel."
   -------------------------------------------------------------------
   | 2 | "This will never, ever sell."
   -------------------------------------------------------------------
   | 3 | "Huh?  I don't understand this at all."
   -------------------------------------------------------------------
   | 4 | "You forgot one little obscure reference from twenty years
   |   |  ago that renders your whole idea null and void."
   -------------------------------------------------------------------
   | 5 | "Due to the number of submissions, we could not accept every
   |   |  transcript."
   -------------------------------------------------------------------
   | 6 | "There aren't enough charts and graphs.  Where is the color?"
   -------------------------------------------------------------------
   | 7 | "I'm cranky and decided to take it out on you."
   -------------------------------------------------------------------
   | 8 | "This is not in within the scope of what we are looking for."
   -------------------------------------------------------------------
   | 9 | "This is too derivative."
   -------------------------------------------------------------------
   |10 | "Your submission was received after the deadline.  Try again
   |   |  next year."
   -------------------------------------------------------------------

   If the CRITIC uses a reject code of 0, then the textual response
   must use an encryption scheme that is selected by the CRITIC.
   Since the PAN protocol does not specify how a ZOO may determine
   what scheme is being used, the ZOO might not be able to understand
   the CRITIC's response.




Christey                     Informational                     [Page 15]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


8.4. Example ZOO-to-CRITIC Session using PAN

   Below is a sample session from a ZOO (SanDiego) to a CRITIC
   (NoBrainer).

     NoBrainer> SIGH Abandon hope all who enter here
     SanDiego> COMPLIMENT We love your work.  Your words are like
     SanDiego> COMPLIMENT jewels and you are always correct.
     SanDiego> TRANSCRIPT RomeoAndJuliet.BoBo.763 251
     NoBrainer> IMPRESS_ME
     SanDiego> Two households, both alike in dignity,
     SanDiego> In fair Verona, where we lay our scene,
     SanDiego> From ancient grudge break to new mutiny,
     SanDiego> Where civil blood makes civil hands unclean.
     SanDiego> From forth the fatal loins of these two foes
     SanDiego> A pair of star-cross'd lovers take their life;
     NoBrainer> REJECT 2    ("This will never, ever sell.")
     SanDiego> THANKS
     NoBrainer> DONT_CALL_US_WE'LL_CALL_YOU

9. Security Considerations

   In accordance with the principles of the humane treatment of
   animals, the design of IMPS specifically prohibits the CRITIC from
   contacting the SIMIAN directly and hurting its feelings.  BARDs
   and CRITICs are also separated because of fundamental
   incompatibilities and design flaws.

   The security considerations for the rest of IMPS are similar to
   those for the original Internet protocols.  Specifically, IMPS
   refuses to learn from the mistakes of the past and blithely
   repeats the same errors without batting an eye.  Spoofing and
   denial of service attacks abound if untrusted entities gain access
   to an IMPS network.  Since all transmissions occur in cleartext
   without encryption, innovative works are subject to theft, which
   is not a significant problem unless the network contains entities
   other than CRITICs.  The open nature of BARDs with respect to
   IAMB-PENT messages allows a BARD to borrow heavily from
   transmitted works, but by design BARDs are incapable of stealing
   transcripts outright.

   The ZOO may be left open to exploitation by pseudo-SIMIANs from
   around the world.  A third party could interrupt communications
   between a ZOO and a SIMIAN by flooding the SIMIAN with packets,
   incrementing the message ID by 1 for each packet.  More heinously,
   the party could exploit the KEEPER protocol by sending a single
   STOP request to each SIMIAN, thus causing a massive denial of
   service throughout the ZOO.  The party could also spoof a CHIMP



Christey                     Informational                     [Page 16]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


   request or send false information such as a DEAD status, which
   could cause a ZOO to attempt to replace a monkey that is still
   functioning properly.

   In addition, if a ZOO repeatedly rejects a SIMIAN's requests
   (especially those for FOOD, WATER, and VETERINARIAN), then the ZOO
   may inadvertently cause its own denial of service with respect to
   that particular SIMIAN.  However, both KEEPER and CHIMP allow the
   ZOO to detect this condition in a timely fashion via the
   NORESPONSE or DEAD status codes.

   All BARDs are inherently insecure because they face insurmountable
   financial problems and low prioritization, which prevents them
   from working reliably.  In the rare cases when a BARD
   implementation overcomes these obstacles, it is only successful
   for 15 minutes, and reverts to being insecure immediately
   thereafter [14].  Since a CRITIC could significantly reduce the
   success of a BARD with an appropriate PAN response, this is one
   more reason why BARDs and CRITICs should always be kept separate
   from each other.

   It is expected that very few people will care about most
   implementations of CRITIC, and CRITICs themselves are inherently
   insecure.  Therefore, security is not a priority for CRITICs.  The
   CRITIC may become the victim of a denial of service attack if too
   many SIMIANs submit transcripts at the same time.  In addition,
   one SIMIAN may submit a non-innovative work by spoofing another
   SIMIAN (this is referred to as the Plagiarism Problem).  A CRITIC
   response can also be spoofed, but since the only response
   supported in PAN version 1 is REJECT, this is of little
   consequence.  Care must be taken in future versions if a
   GRUDGING_ACCEPTANCE response is allowed.  Finally, a transcript
   may be lost in transmission, and PAN does not provide a mechanism
   for a ZOO to determine if this has happened.  Future versions of
   IMPS may be better suited to answer this fundamental design
   problem: if an innovative work is lost in transmission, can a
   CRITIC still PAN it?

   Based on the number of packet-level vulnerabilities discovered in
   recent years, it is a foregone conclusion that some
   implementations will behave extremely poorly when processing
   malformed IMPS packets with incorrect padding or reserved bits
   [15] [16] [17].








Christey                     Informational                     [Page 17]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


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

10. Acknowledgements

   The author wishes to thank Andre Frech for technical comments that
   tripled the size of this document, Kean Kaufmann and Amanda
   Vizedom for lectures on Shakespearean grammar, Rohn Blake for
   clarifying the nature of the entire universe, William Shakespeare
   for accents, the number 16, and the color yellow.

11. References

   [1]  The Famous Brett Watson, "The Mathematics of Monkeys and
        Shakespeare."  http://www.nutters.org/monkeys.html

   [2]  Dr. Math. "Monkeys Typing Shakespeare: Infinity Theory."
        http://forum.swarthmore.edu/dr.math/problems/bridge8.5.98.html

   [3]  K. Clark, Stark Mill Brewery, Manchester, NH, USA.  Feb 18,
        2000.  (personal communication).  "Good question!  I never thought
        of that!  I bet nobody else has, either.  Please pass the french
        fries."

   [4]  The author was unable to find a reference in any issue of TV
        Guide published between 1956 and the date of this document.

   [5]  "Dough Re Mi," The Brady Bunch.  Original air date January 14,
        1972.

   [6]  Postel, J., " Internet Protocol", STD 5, RFC 791, September 1981.

   [7]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [8]  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
        Relay", STD 55, RFC 2427, September 1998.

   [9]  Internet-Draft, bernstein-netstrings-06 (expired Work in
        Progress).  D.J. Bernstein.  Inclusion of this reference is a
        violation of RFC 2026 section 2.2.

   [10] Glassman, S., Manasse, M. and J. Mogul, "Y10K and Beyond", RFC
        2550, 1 April 1999.




Christey                     Informational                     [Page 18]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


   [11] "My Last Theorem: A Prankster's Guide to Ageless Mathematical
        Jokes That are Funny Because They're True and People Can't Prove
        Them for Centuries."  P. Fermat.  Circa 1630.

   [12] .signature in various USENET postings, circa 1994.  Author
        unknown.

   [13] "Recognizing Irony, or How Not to be Duped When Reading."
        Faye Halpern.  1998.
        http://www.brown.edu/Student_Services/Writing_Center/halpern1.htm

   [14] Andy Warhol.  Circa 1964.

   [15] CERT Advisory CA-98-13.  CERT.  December 1998.
        http://www.cert.org/advisories/

   [16] CERT Advisory CA-97.28.  CERT.  December 1997.
        http://www.cert.org/advisories/

   [17] CERT Advisory CA-96.26.  CERT.  December 1996.
        http://www.cert.org/advisories/

   [18] All issues of TV Guide published between 1956 and the date of
        this document.

12. Author's Address

   SteQven M. Christey
   EMail: [e-mail]






















Christey                     Informational                     [Page 19]

RFC 2795       The Infinite Monkey Protocol Suite (IMPS)    1 April 2000


13.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Christey                     Informational                     [Page 20]