UTF-9

A Request for Comments (RFC), in the context of Internet governance, is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC), usually describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.

Almost every April Fools' Day (1 April) since 1989, the Internet RFC Editor has published one or more humorous Request for Comments (RFC) documents, following in the path blazed by the June 1973 RFC  called ARPAWOCKY, a parody of Lewis Carroll's nonsense poem "Jabberwocky". The following list also includes humorous RFCs published on other dates.

List of April Fools' Day RFCs

*
:: A parody of the TCP/IP documentation style. For a long time it was specially marked in the RFC index with "note date of issue".

*

*
:: Updated by RFC 2549 in 1999; see below. Describes protocol for transmitting IP packets by homing pigeon.
:: In 2001, RFC 1149 was actually implemented by members of the Bergen Linux User Group.
:: See also RFC 6214, as noted below. Describes the adaptation of RFC 1149 for IPv6.
:

*
*

*

*
*

*
::Attributed to William Shakespeare.
*
*

*

*
*
*
*

*

*
*
:: This RFC is not solely for entertainment; the described protocol has regularly been implemented at hacker events in Europe.
*
* Updated by RFC 7168 in 2014.
:
*

* Updates RFC 1149.
:
*
* Obsoletes MCMXCIX.

*
:: Concerning the practicalities of the infinite monkey theorem.

*
*
*

*
::Parody of "Everything over IP and IP over Everything" and the 2000–2001 California electricity crisis.
*

*
:: Proposal for the ' evil bit', as an option in the IPv4 packet header. Later, this became a synonym for all attempts to seek simple technical solutions for difficult human social problems which require the willing participation of malicious actors.
:

*

*
*
::Notable for containing PDP-10 assembly language code nearly 22 years after the manufacturer ceased production of the PDP-10, and for being technically possible as opposed to many of these other proposals.
*RFC Draft: "IP over Burrito Carriers"
::An internet protocol recipe, to communicate while eating.

:An April 1st RFC was not published this year, but an /www.ietf.org/mail-archive/web/ietf/current/msg41460.html announcement on the IETF listabout the appointment of the ''Sesame Street'' character Bert as member of the IAB appears to have been the April Fools' Day 2006 stunt.

*
:
:

*
*

*
*
:: Implemented on Facebook by the author, in the process of writing the RFC.

*

*
:
*

*
::Although mentioned in several networking protocols (like MPEG-2, RTP, or RTCP) the Null Packet has never been formally defined. This RFC corrects that omission by providing an empty definition. Null packets are zero-dimensional, zero length, benign packets (i.e. lacking an ''Evil bit''), that can be quite elusive. Interestingly, the rate at which Null Packets are sent does not increase the bit rate of the Null Packet traffic.
*
::Most services eagerly choose to be fully visible in the network so users may find them easily (by means of one of the many service discovery techniques), but "an apathetic, playful, overwhelmed, or shy service might prefer a hide or hint engagement, instead of directly showing itself." To do so, this RFC introduces a hide-and-seek paradigm, where the service (the "hider") has the option of several techniques for hiding from the client (in this scenario called "it"). DPS packets are sent over TCP with the ''Mood'' set to 'Sneaky' (see above) and with their ''Evil bit'' set (see above). The latter now ambiguously means "I am not sure" to further enhance the protocol.

*
::Enhances the ability of the RFC's author to also convey intention and purpose in a more informal way, with (in)directive key words, like: "MUST (BUT WE KNOW YOU WON'T)" (when you know beforehand you will be ignored, but to come out morally superior anyway) and "REALLY SHOULD NOT" (when it is to be expected that 'boys will be boys').
*
::When it becomes possible to send packets over the Internet faster than light, they may be received before they are sent (due to time reversal), which will have major impact on many protocols in use today. With sufficient speed (and corresponding negative time shift), a complete communication may have taken place before it even has started. The RFC reviews the design principles of those protocols, to prevent future breakdown of communication. Most likely, we should have started upgrading them yesterday.
:
:

*
::Updates for coffee machines which are also capable of brewing tea. Also defines the HTTP response code ''418 I'm a Teapot'', for teapots to use when unable to brew coffee.
:
*
::Although generally unwanted, private key counterparts of X509 digital certificates may have been or have been shared with a third party, for lawful interception or other reasons. Users may now be notified of this fact with a new certificate extension, specifying the boolean value ext-KeyUsage. When 'true', the private key has been shared; when 'false', the signer abstains from commenting on whether or not sharing has taken place.

*
:: Green IT has become increasingly important. In a win-win proposition, for packets and the environment alike, this RFC defines a way to allow packets to be routed through the air, to get as much sunlight and fresh air possible. Sending packets over Wi-Fi or by pigeons will help them escape their torturous routine of assembly and disassembly, and being shot through dark fibers and copper cables all the time.
*
::In an approach similar to the now deprecated ICMP Source Quench, it reuses that packet's 'Type' field (4) to tell the sender (really more explicitly than ECN) to shut up. The user responsible for the traffic MUST be made aware of the contents of an RECN message by means of text-to-speech, or pop-ups if the audio channel is muted.

: An April 1st RFC was not published this year.

*
::Takes a rather mathematical approach to use the 128-bit IPv6 address space in other ways than the traditional one, to ultimately arrive at Complex Addresses. You may use the imaginary part of a complex address (with polar coordinates as the real part) to reach Santa Claus, for example. It also proposes to use Flying Addresses for end hosts using IP over avian carriers.
*
::As the Internet Architecture Board intends to relax requirements for compatibility with IPv4 for new or extended protocols, this RFC helps the adoption of IPv6 by setting the evil bit for all IPv4 packets to , making sure that dual stack hosts will favor IPv6, as will the Happy Eyeballs algorithm. To maintain functional equivalence between IPv4 and IPv6, the 'security flag' of should be included in the IPv6 header. Advanced security options may be specified in a new hop-by-hop option header.
*
:: ASCII art in its most splendid form. Depicts and annotates fruit bats, the Loch Ness monster, some fundamental Bauhaus elements, and even a flock of avian carriers.

*
::A heartfelt cry to end packet discrimination at the IP level, where they frequently (even in this day and age) are terminated prematurely, based on color, length, age, etcetera, or even by IP version!
*
::Proposes to use 128-bit Unicode to facilitate internationalization of IPv6, since the 1.114.112 code points of the current implementation of Unicode is deemed insufficient for the future. IPv6 addresses may be represented by a single U+128 glyph, to reduce stress on the eyes of network administrators.
::If implemented, it would obsolete , because " was found to be too complex to implement anyway".

*
:: A 'response/request' protocol similar to HTTP/1.1 but where clients send a response to the server (e.g. "Hello World. My payload includes a trailing CRLF.") to which the server answers with a request (e.g. GET /hello.txt), like in the Jeopardy! game. The Hypertext Double Jeopardy Protocol (HTJ2P) (described in Appendix A) inverses the semantics of HTJP again.
*
:: The authors contend that the DNS (secured with DNSSEC) is most suited to globally and reliably provide information to help maintain a high quality of experience for CPE (among others). With the definition of four new DNS RR types (password, credit card number, social security number, and an SSN pointer record) they hope to create end-to-end, holistic network management.

*
::A proposal to use UTF-8 to obfuscate (and help replace) textual IP addresses, to coerce a small minority of people to use the DNS instead of sticking to (and mixing up) plain IP addresses.
*
::Dismisses with the notion that considering time travel for faster-than-light packet delivery is "amusing" but impossible as a concept. Instead, it focuses on real life quantum entanglement in relation to packet round trip times, which (depending on the observer) could reach zero. This may cause havoc among several protocols, which should be fixed "in time" before things break.

*
::Since the Internet Engineering Task Force claims it "is not the Protocol Police", it is formally established here. It polices various aspects of protocol definitions laid out by the RFC series, and enforces adherence to them. They are sanctioned to access walled gardens and may even resort to traffic imprisonment. By the way: if you are interested in joining the Protocol Police, contact your localhost.

*
::Discourages the practice of introducing software defects, to reduce costs and lessen security impacts. By introducing some best current practices the authors hope to get rid of them: "Authors MUST NOT implement bugs. If bugs are introduced in code, they MUST be clearly documented."
*
::Known problems with hexadecimal representation of numbers can be avoided by replacing its alphabet of 0-9 and A-F with two octal ranges: 0-7 and the letters 'cjzwfsbv' (to represent values 8-15 in a bitwise elegant way).

*
::As is customary in light novels, a 'death flag' indicates the increased likelihood of a swift demise of the character. Transferred to TCP, the DTH flag in the packet header could lead to smoother and more attractive session narratives.
*
::Finally, a formalized way (with a ABNF grammar description) to properly describe the interaction between cats and containers, including the occasional ball of yarn.
*
::The AI Sarcasm Detection Protocol (ASDP) is a framework for detecting sarcasm in AI systems (written with the help of ChatGPT). Detecting sarcasm may help improve AI - human intercommunication.

*
::The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than Light speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.

*
::Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.

Other humorous RFCs

*
::Transcript of a talk of the schizophrenic chatbot PARRY with the computer simulated psychiatrist ELIZA (a.k.a. 'The Doctor') which both fail the Turing test with flying colours.
*
::A very ' ARPA-ish' parody of Lewis Caroll's nonsense poem 'Jabberwocky'.
*
::A poem that discusses problems that arise, and debugging techniques used, in bringing a new network into operation. It shows that array indexing is problematic since the olden days.
*
::A parody of the Christmas carol ' The Twelve Days of Christmas', where computer problems pile up and the IT staff is swamped, like on a regular day.
*
::Introducing the NULL encryption algorithm, mathematically defined as the Identity function: , provides the means for Encapsulating Security Payload to provide authentication and integrity, but without confidentiality.

Submission of April Fools' Day RFCs

The RFC Editor accepts submission of properly formatted April Fools' Day RFCs from the general public, and considers them for publication in the same year if received at least two weeks prior to April 1st. This practice of publishing April Fool's Day RFCs is specifically acknowledged in the instructions memo for RFC authors, with a tongue-in-cheek note saying: "Note that in past years the RFC Editor has sometimes published serious documents with April 1 dates. Readers who cannot distinguish satire by reading the text may have a future in marketing."

References

Further reading

* /www.rfc-editor.org/ RFC Editor home page– hosts individual RFCs

External links

* – on RFC 3751 and April Fools' Day RFCs in general.
* {{cite book , title=The Complete April Fools' Day RFCs , last= Limoncelli , first= Thomas A., author2=Peter H. Salus , year= 2007, publisher= Peer-to-Peer Communications, isbn= 978-1-57398-042-5

April Fools' Day jokes
Request for Comments
Computer humour
Hacker culture