Requests For Comments ... for the community
Welcome to OpenRFC
Home Full RFC index RFC humour Our technology

Smile Standard humour

We consider this to be the authoritative source of humourous RFCs (a.k.a., RFCs that contain "Easter Eggs").  One thing that most technical people come to realize after working in a given industry for any significant amount of time is that a few dashes of humour ("- - -"), possibly surrounded by a few dots (". . .") on either side, can help to make the work more enjoyable (tolerable, etc.).

Although a few RFCs contain humourous portions only, the vast majority, most of which are coincidentally dated on the 1st day of the month of April, are funny in their entireties.  To us, one of the most notable is RFC 2324, the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), which pokes fun at HTTP (a real protocol that has become hugely popular).


Funny RFCs

This list also includes short abstracts of these funny RFCs along with direct links to the original texts.  If you have too much time on your hands, then this is probably the right web page for you!

RFC 439:  PARRY encounters the DOCTOR. V. Cerf. January 1973.
This is a recorded session of a text-based conversation in 1972 between two parties that many find entertaining.

RFC 527:  ARPAWOCKY. R. Merryman. May 1973.

RFC 748:  Telnet randomly-lose option. M.R. Crispin. April 1 1978.
A sarcastic attempt to document that which cannot be documented because it was lost.

RFC 873:  Illusion of vendor support. M.A. Padlipsky. September 1982.
The sometimes-held position that "vendor supplied" intercomputer networking protocols based upon the International Standards Organization's Reference Model for Open System Interconnection are worth waiting for, in particular in preference to protocols based upon the ARPANET Reference Model (ARM), is shown to be fallacious.

RFC 968:  Twas the night before start-up. V.G. Cerf. December 1985.
This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.

RFC 1097:  Telnet subliminal-message option. B. Miller. April 1 1989.
Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.

RFC 1121:  Act one - the poems. J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm. September 1989.
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.

RFC 1149:  Standard for the transmission of IP datagrams on avian carriers. D. Waitzman. April 1 1990.
This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers.  This specification is primarily useful in Metropolitan Area Networks.

See also:  RFC 2549

RFC 1216:  Gigabit network economics and paradigm shifts. P. Richard, P. Kynikos. April 1 1991.
This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track.

RFC 1217:  Memo from the Consortium for Slow Commotion Research (CSCR). V.G. Cerf. April 1 1991.
This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts."

RFC 1290:  There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. December 1991.
The title of this document is humourous.  The document is serious.

See also:  RFC 1402

RFC 1300:  Remembrances of Things Past. S. Greenfield. February 1992.

RFC 1313:  Today's Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. April 1 1992.
A parody of RFC writing in a style that an AM radio announcer might use.

RFC 1391:  The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. January 1993.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works.  This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone.  This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

Hint:  To find the good stuff, search this document for the keywords "hungry" or "BOF" or "beer" and also read some of the headings.  There's even mention of recouping costs for pocket protectors (search only for the word "pocket" though)!

RFC 1402:  There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. January 1993.
The title of this document is humourous.  The document is serious.

Obsoletes:  RFC 1290

RFC 1437:  The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. April 1 1993.
A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail.  This document defines one particular type of MIME data, the matter-transport/sentient-life-form type.  The matter-transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.

Other informally proposed subtypes, such as "non-sentient-life-form," "non-sentient-non-life-form," and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form," are not described in this memo.

See also:

RFC 1438:  Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. April 1 1993.
The IETF currently has no mechanism or means of publishing documents that express its deep concern about something important, but otherwise contain absolutely no useful information whatsoever.  This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs).  The SOB process is similar to that of the normal standards track.  The SOB is submitted to the IAB, the IRSG, the IESG, the SOB Editor (Morpheus), and the Academie Francais for review, analysis, reproduction in triplicate, translation into ASN.1, and distribution to Internet insomniacs.  However, once everyone has approved the document by falling asleep over it, the process ends and the document is discarded.  The resulting vacuum is viewed as having the technical approval of the IETF, but it is not, and cannot become, an official Internet Standard.

RFC 1605:  SONET to Sonnet Translation. W. Shakespeare. April 1 1994.
Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link.  This memo describes a particular method, SONET Over Novel English Translation (SONNET).

RFC 1606:  A Historical Perspective On The Usage Of IP Version 9. J. Onions. April 1 1994.
This paper reviews the usages of the old IP version protocol.  It considers some of its successes and its failures.

RFC 1607:  A VIEW FROM THE 21ST CENTURY. V. Cerf. April 1 1994.
The letters transcribed within this RFC were discovered in September 1993 in a reverse time-capsule apparently sent from 2023.  The author of this paper cannot vouch for the accuracy of the letter contents, but spectral and radiation analysis are consistent with origin later than 2020.  It is not known what, if any, effect will arise if readers take actions based on the future history contained in these documents.  I trust you will be particularly careful with our collective futures!

RFC 1776:  The Address is the Message. S. Crocker. April 1 1995.
Security experts hailed this as a major breakthrough.  With no content left in the packets, all questions of confidentiality and integrity are moot.  Intelligence and law enforcement agencies immediately refocused their efforts to detect who's talking to whom, and are silently thankful they can avoid divisive public debate about key escrow, export control and related matters.

RFC 1861:  Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A. Gwinn. October 1995.
This serious RFC contains a parody of the famous "Little Bo Peep" fairy tale in section 4.1.3, which begins with "Little Bo Binary has lost her Sparcstation..."

RFC 1882:  The 12-Days of Technology Before Christmas. B. Hancock. December 1995.
A parody of "The 12 Days Of Christmas."

RFC 1924:  A Compact Representation of IPv6 Addresses. R. Elz. April 1 1996.
IPv6 addresses, being 128 bits long, need 32 characters to write in the general case, if standard hex representation, is used, plus more for any punctuation inserted (typically about another 7 characters, or 39 characters total).  This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes.

RFC 1925:  The Twelve Networking Truths. R. Callon. April 1 1996.
This memo documents the fundamental truths of networking for the Internet community.  This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.

RFC 1926:  An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. April 1 1996.
This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM).

RFC 1927:  Suggested Additional MIME Types for Associating Documents. C. Rogers. April 1 1996.
Introduces new MIME Types, Staple and "Paper" Clip, and discusses patents, recycling, customization, and various hazards related to these items.

RFC 2100:  The Naming of Hosts. J. Ashworth. April 1 1997.
Poetry (with a nice introduction).

RFC 2321:  RITA -- The Reliable Internetwork Troubleshooting Agent. A. Bressen. April 1 1998.
A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments.

RFC 2322:  Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, R. van Mook. April 1 1998.
This RFC describes a protocol (that relies on "HIP" {Hacking In Progress} events) to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body.

It can also provide some fixed additional fields global for all clients like netmask and even autoproxyconfigs.  It does not depend on a particular ip-stack.

RFC 2323:  IETF Identification and Security Guidelines. A. Ramos. April 1 1998.
This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis."

This document will shed further illumination on these problems and provide some possible solutions.

This memo provides entertainment for the Internet community.  It does not specify an Internet standard of any kind, but is rather unstandard, actually.  Please laugh loud and hard.

RFC 2324:  Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. April 1 1998.
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.

See also:  RFC 2325

RFC 2325:  Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2. M. Slavitch. April 1 1998.
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for the management of coffee-brewing and maintenance devices.

See also:  RFC 2324

RFC 2549:  IP over Avian Carriers with Quality of Service. D. Waitzman. April 1 1999.
This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers," with Quality of Service information.

RFC 2550:  Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. April 1 1999.
As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem.  Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000.  Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals).

RFC 2551:  The Roman Standards Process -- Revision III. S. Bradner. April 1 1999.
This memo documents the process used by the Roman community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.

RFC 2795:  The Infinite Monkey Protocol Suite (IMPS). S. Christey. April 1 2000.
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.

RFC 3091:  Pi Digit Generation Protocol. H. Kennedy. April 1 2001.
This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers.

RFC 3092:  Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. April 1 2001.
Approximately 212 RFCs so far, starting with RFC 269, contain the terms "foo," "bar," or "foobar," as metasyntactic variables without any proper explanation or definition.  This document rectifies that deficiency.

RFC 3093:  Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. April 1 2001.
Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].  However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation.  We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall.  With no cooperation from a firewall operator, the FEP allows ANY application to traverse a Firewall.  Our methodology is to layer any application layer Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, since HTTP packets are typically able to transit Firewalls.  This scheme does not violate the actual security usefulness of a Firewall, since Firewalls are designed to thwart attacks from the outside and to ignore threats from within.  The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall.  FEP allows the best of both worlds:  the security of a firewall, and transparent tunneling thought the firewall.

RFC 3251:  Electricity over IP. B. Rajagopalan. April 1 2002.
Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane).  According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity.  This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors).  Readers of the previous work have been observed scratching their heads and muttering, "What next?"  This document answers that question.

This document has also been written as a public service.  The "Sub-IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents.  There are possibly many who are wondering how to exploit this opportunity and attain high visibility.  Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents.  This document illustrates the key ingredients that go into producing any "foo-over-MPLS" document and may be used as a template for all such work.

RFC 3252:  Binary Lexical Octet Ad-hoc Transport. H. Kennedy. April 1 2002.
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.

Given the rediculous amount that XML is overused, we suspect that the spirit of the ideas portrayed in this document were mistakenly taken too far.

RFC 3514:  The Security Flag in the IPv4 Header. S. Bellovin. April 1 2003.
Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual.  We define a security flag in the IPv4 header as a means of distinguishing the two cases.

RFC 3751:  Omniscience Protocol Requirements. S. Bradner. April 1 2004.
There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users.  This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts.

RFC 4041:  Requirements for Morality Sections in Routing Area Drafts. A. Farrel. April 1 2005.
It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area.  This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.

This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain.

RFC 4042:  UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. April 1 2005.
ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems.  The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details.  By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 646 track each other, so that the character repertoires and code point assignments remain in synchronization.

The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.

This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient.

RFC 4641:  DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006.
The first paragraph on page 31 contains an easter egg that includes the words "singing" and "joyfully."  At first glance singing seems like an innocent mis-spelling of signing, even to the average speed reader, which increases the difficulty of finding it.

Thanks to Jeremy C. Reed of Reed Media Services, the publisher of DNSSEC Specifications, for finding this easter egg and notifying us on 2010-Nov-06.

RFC 4824:  The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS). J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. April 1 2007.
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).

RFC 5241:  Naming Rights in IETF Protocols. A. Falk, S. Bradner. April 1 2008.
This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields.  This memo describes a process for assignment of rights and explores some of the issues associated with the process.  Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.

RFC 5242:  A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand. April 1 2008.
Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes.  This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters.  It is not a complete specification of that character set.

RFC 5257:  Internet Message Access Protocol - ANNOTATE Extension. C. Daboo, R. Gellens. June 2008.
The last example in section 4.3 on page 14 includes a few humour annotations referencing a "chowder-head" and the crushing of beer cans.

RFC 5513:  IANA Considerations for Three Letter Acronyms. A. Farrel. April 1 2009.
Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF.  A common concern is that one acronym may have multiple expansions.  While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity.  This results in contention for acronyms, and confusion in interpretation.  Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

RFC 5514:  IPv6 over Social Networks. E. Vyncke. April 1 2009.
There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low.  This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.  This will immediately add millions of IPv6 hosts to the existing IPv6 Internet.  This document includes sections on addressing and transport of IPv6 over a Social Network.  A working prototype has been developed.

RFC 5841:  TCP Option to Denote Packet Mood. R. Hay, W. Turkal. April 1 2010.
Packets cannot feel.  They are created for the purpose of moving data from one system to another.  However, it is clear that in specific situations some measure of emotion can be inferred or added.  For instance, a packet that is retransmitted to resend data for a packet for which no ACK was received could be described as an "angry" packet, or a "frustrated" packet (if it is not the first retransmission for instance).



[Home] [Full RFC index] [RFC humour] [Our technology]

Copyright © Inter-Corporate Computer & Network Services, Inc.  All rights reserved.
All trademarks and RFC contents are the property of their respective owners.