View source for April Fools' Day Request for Comments

{{Short description|List of humorous technical standards proposals}}
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&nbsp;{{va|527}} called ARPAWOCKY, a [[parody]] of [[Lewis Carroll]]'s [[Nonsense verse|nonsense poem]] "[[Jabberwocky]]". The following list also includes [[humour|humor]]ous RFCs published on other dates.

== List of April Fools' Day RFCs ==
==={{visible anchor|1978}}===

*{{Sum RFC|748|ref=yes|refnotes=no}}
:: A parody of the [[Internet protocol suite|TCP/IP]] documentation style. For a long time it was specially marked in the RFC index with "note date of issue".

==={{visible anchor|1989}}===
*{{Sum RFC|1097|ref=yes|refnotes=no}}

==={{visible anchor|1990}}===
*{{Sum RFC|1149|ref=yes|refnotes=no}}
:: Updated by RFC 2549 in 1999; see below. Describes protocol for transmitting IP packets by [[homing pigeon]].
:: In 2001, RFC 1149 was actually implemented<ref>{{cite web |url=http://www.blug.linux.no/rfc1149/ |title=RFC 1149 implemented |publisher=Blug.linux.no |access-date=2012-03-18 |archive-url=https://web.archive.org/web/20111004221306/http://www.blug.linux.no/rfc1149/ |archive-date=2011-10-04 |url-status=dead }}</ref> by members of the [[Bergen]] [[Linux User Group]].
:: See also RFC 6214, as noted below. Describes the adaptation of RFC 1149 for [[IPv6]].
:{{see|IP over Avian Carriers}}

==={{visible anchor|1991}}===
*{{Sum RFC|1216|ref=yes|refnotes=no}}
*{{Sum RFC|1217|ref=yes|refnotes=no}}

==={{visible anchor|1992}}===
*{{Sum RFC|1313|ref=yes|refnotes=no}}

==={{visible anchor|1993}}===
*{{Sum RFC|1437|ref=yes|refnotes=no}}
*{{Sum RFC|1438|ref=yes|refnotes=no}}

==={{visible anchor|1994}}===
*{{Sum RFC|1605|ref=yes|refnotes=no}}
::Attributed to [[William Shakespeare]].
*{{Sum RFC|1606|ref=yes|refnotes=no}}
*{{Sum RFC|1607|ref=yes|refnotes=no}}

==={{visible anchor|1995}}===
*{{Sum RFC|1776|ref=yes|refnotes=no}}

==={{visible anchor|1996}}===
*{{Sum RFC|1924|ref=yes|refnotes=no}}
*{{Sum RFC|1925|ref=yes|refnotes=no}}
*{{Sum RFC|1926|ref=yes|refnotes=no}}
*{{Sum RFC|1927|ref=yes|refnotes=no}}

==={{visible anchor|1997}}===
*{{Sum RFC|2100|ref=yes|refnotes=no}}

==={{visible anchor|1998}}===
*{{Sum RFC|2321|ref=yes|refnotes=no}}
*{{Sum RFC|2322|ref=yes|refnotes=no}}
:: This RFC is not solely for entertainment; the described protocol has regularly been implemented at hacker events in Europe. 
*{{Sum RFC|2323|ref=yes|refnotes=no}}
*{{Sum RFC|2324|ref=yes|refnotes=no}} Updated by RFC 7168 in 2014.
:{{see|Hyper Text Coffee Pot Control Protocol}}
*{{Sum RFC|2325|ref=yes|refnotes=no}}

==={{visible anchor|1999}}===
*{{Sum RFC|2549|ref=yes|refnotes=no}} Updates RFC 1149.
:{{see|IP over Avian Carriers}}
*{{Sum RFC|2550|ref=yes|refnotes=no}}
*{{Sum RFC|2551|ref=yes|refnotes=no}} Obsoletes MCMXCIX.

==={{visible anchor|2000}}===
*{{Sum RFC|2795|ref=yes|refnotes=no}}
:: Concerning the practicalities of the [[infinite monkey theorem]].

==={{visible anchor|2001}}===
*{{Sum RFC|3091|ref=yes|refnotes=no}}
*{{Sum RFC|3092|ref=yes|refnotes=no}}
*{{Sum RFC|3093|ref=yes|refnotes=no}}

==={{visible anchor|2002}}===
*{{Sum RFC|3251|ref=yes|refnotes=no}}
::Parody of "Everything over IP and IP over Everything"{{Ref RFC|5218}} and the [[2000–2001 California electricity crisis]].
*{{Sum RFC|3252|ref=yes|refnotes=no}}

==={{visible anchor|2003}}===
*{{Sum RFC|3514|ref=yes|refnotes=no}}
:: Proposal for the '[[evil bit]]', as an option in the [[IPv4#header|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.
:{{see|Evil bit}}

==={{visible anchor|2004}}===
*{{Sum RFC|3751|ref=yes|refnotes=no}}

==={{visible anchor|2005}}===
*{{Sum RFC|4041|ref=yes|refnotes=no}}
*{{Sum RFC|4042|ref=yes|refnotes=no}}
::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"<ref>{{cite IETF | draft=draft-lohsen-ip-burrito-00| title=IP over Burrito Carriers| author= M. Schulze| author2=W. Lohsen|date=1 April 2005|publisher=[[Internet Engineering Task Force]]}}</ref>
::An [[internet protocol]] recipe, to communicate while eating.

==={{visible anchor|2006}}===
: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 list] about the appointment of the ''[[Sesame Street]]'' character [[Bert (Sesame Street)|Bert]] as member of the IAB appears to have been the April Fools' Day 2006 stunt.

==={{visible anchor|2007}}===
*{{Sum RFC|4824|ref=yes|refnotes=no}}
:{{Further|topic=its implementation|Semaphore Flag Signaling System}}
:{{Further|topic=competing ways of using flags to convey messages|Flag semaphore}}

==={{visible anchor|2008}}===
*{{Sum RFC|5241|ref=yes|refnotes=no}}
*{{Sum RFC|5242|ref=yes|refnotes=no}}

==={{visible anchor|2009}}===
*{{Sum RFC|5513|ref=yes|refnotes=no}}
*{{Sum RFC|5514|ref=yes|refnotes=no}}
:: Implemented on [[Facebook]] by the author, in the process of writing the RFC.<ref name=IPv6overFacebook>{{Cite web|title=IPv6 over the Facebook Social Network|author=E. Vyncke|url=//tools.ietf.org/html/rfc5514#ref-IPv6overFacebook}}</ref>

==={{visible anchor|2010}}===
*{{Sum RFC|5841|ref=yes|refnotes=no}}

==={{visible anchor|2011}}===
*{{Sum RFC|6214|ref=yes|refnotes=no}}
:{{Further|IP over Avian Carriers}}
*{{Sum RFC|6217|ref=yes|refnotes=no}}

==={{visible anchor|2012}}===
*{{Sum RFC|6592|ref=yes|refnotes=no}}
::Although mentioned in several networking protocols (like [[MPEG-2]], [[Real-time Transport Protocol|RTP]], or [[RTP Control Protocol|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.
*{{Sum RFC|6593|ref=yes|refnotes=no}}
::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 [[Transport Control Protocol|TCP]] with the ''Mood'' set to 'Sneaky' (see {{IETF RFC|5841|link=no}} above) and with their ''Evil bit'' set (see {{IETF RFC|3514|link=no}} above). The latter now ambiguously means "I am not sure" to further enhance the protocol.

==={{visible anchor|2013}}===
*{{Sum RFC|6919|ref=yes|refnotes=no}}
::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').
*{{Sum RFC|6921|ref=yes|refnotes=no}}
::When it becomes possible to send packets over the Internet [[faster than light]], they may be received before they are sent (due to [[Time travel|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.
:{{Further|topic=what in this case would be called 'Backward Error Correction'|Forward Error Correction}} 
:{{Further|topic=another approach to this imminent disaster (predicting packets rather than implementing time resilience)|April Fools' Day Request for Comments#2024}}

==={{visible anchor|2014}}===
*{{Sum RFC|7168|ref=yes|refnotes=no}}
::Updates {{IETF RFC|2324}} for [[coffee machine]]s which are also capable of brewing [[tea]]. Also defines the [[HTTP response code]] ''418 I'm a Teapot'', for [[teapot]]s to use when unable to brew [[coffee]].
:{{Further|Hyper Text Coffee Pot Control Protocol}}
*{{Sum RFC|7169|ref=yes|refnotes=no}}
::Although generally unwanted, [[private key]] counterparts of [[X509]] [[digital certificate]]s 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 <code>ext-KeyUsage</code>. When 'true', the private key has been shared; when 'false', the signer abstains from commenting on whether or not sharing has taken place.

==={{visible anchor|2015}}===
*{{Sum RFC|7511|ref=yes|refnotes=no}}
::[[Green computing|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 [[Routing|routed]] through the air, to get as much sunlight and fresh air possible. Sending packets over [[Wi-Fi]] or by [[IP over avian carriers|pigeons]] will help them escape their torturous routine of assembly and disassembly, and being shot through dark [[Fiber optics|fibers]] and [[Ethernet|copper cables]] all the time.
*{{Sum RFC|7514|ref=yes|refnotes=no|quote=An RECN message SHOULD be sent by a router in response to a host that is generating traffic at a rate persistently unfair to other competing flows and that has not reacted to previous packet losses or ECN marks.}}
::In an approach similar to the now deprecated [[Internet control message protocol|ICMP]] [[Internet control message protocol#source quench|Source Quench]], it reuses that packet's 'Type' field (4) to tell the sender (really more explicitly than [[Explicit congestion notification|ECN]]) to shut up. The user responsible for the traffic MUST be made aware of the contents of an RECN message by means of [[Speech synthesis|text-to-speech]], or [[Modal window|pop-up]]s if the audio channel is muted.

==={{visible anchor|2016}}===
: An April 1st RFC was not published this year.<ref>{{cite mailing list |url=https://mailarchive.ietf.org/arch/msg/rfc-interest/xaHiBCRy26Q9V4-6xL2aHtqY0e8/ |title=hey, guys, where 1 april 2016 RFC. Ups... |date=2 April 2016 |mailing-list= rfc-i |last= Flanagan |first= Heather}}</ref>

==={{visible anchor|2017}}===
*{{Sum RFC|8135|ref=yes|refnotes=no}}
::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 number|complex]] address (with [[Spherical coordinate system|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]].
*{{Sum RFC|8136|ref=yes|refnotes=no}}
::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 {{mono|1}}, 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 {{IETF RFC|3514}} should be included in the [[IPv6 packet#Header|IPv6 header]]. Advanced security options may be specified in a new [[IPv6 header#hop-by-hop options|hop-by-hop]] option header.
*{{Sum RFC|8140|ref=yes|refnotes=no}}
::[[ASCII art]] in its most splendid form. Depicts and annotates [[fruit bat]]s, the [[Loch Ness monster]], some fundamental [[Bauhaus]] elements, and even a flock of [[IP over avian carriers|avian carriers]].

==={{visible anchor|2018}}===
*{{Sum RFC|8367|ref=yes|refnotes=no}}
::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,{{Ref RFC|4115}} [[Jumbo frame|length]], [[Time to live|age]], etcetera, or even by [[IP protocol|IP version]]!
*{{Sum RFC|8369|ref=yes|refnotes=no}}
::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 address]]es may be represented by a single U+128 [[glyph]], to reduce stress on the eyes of network administrators.
::If implemented, it would obsolete {{IETF RFC|8135}}, because "[i]t was found to be too complex to implement anyway".

==={{visible anchor|2019}}===
*{{Sum RFC|8565|ref=yes|refnotes=no}}
:: 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.
*{{Sum RFC|8567|ref=yes|refnotes=no}}
:: The authors contend that the [[Domain name system|DNS]] (secured with [[DNSSEC]]) is most suited to globally and reliably provide information to help maintain a high [[quality of experience]] for [[Customer premises equipment|CPE]] (among others). With the definition of four new DNS [[Domain name system#Resource Records|RR]] types ([[password]], [[credit card number]], [[social security number]], and an SSN [[Reverse DNS lookup|pointer record]]) they hope to create end-to-end, holistic network management.

==={{visible anchor|2020}}===
*{{Sum RFC|8771|ref=yes|refnotes=no}}
::A proposal to use [[UTF-8]] to obfuscate (and help replace) textual [[IP address]]es, to coerce a small minority of people to use the [[Domain Name System|DNS]] instead of sticking to (and mixing up) plain IP addresses.
*{{Sum RFC|8774|ref=yes|refnotes=no}}
::Dismisses {{IETF RFC|6921}} 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 [[Network packet|packet]] [[round trip time]]s, which (depending on the observer) could reach zero. This may cause havoc among several protocols, which should be fixed "in time" before things break.

==={{visible anchor|2021}}===
*{{Sum RFC|8962|ref=yes|refnotes=no|quote=Send all your reports of possible violations and all tips about wrongdoing to [[/dev/null]]. The Protocol Police are listening and will take care of it.}}
::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 garden (technology)|walled garden]]s and may even resort to traffic imprisonment. By the way: if you are interested in joining the Protocol Police, contact your [[localhost]].

==={{visible anchor|2022}}===
*{{Sum RFC|9225|ref=yes|refnotes=no}}
::Discourages the practice of introducing [[Bug (software)|software defects]], to reduce costs and lessen security impacts. By introducing some [[best current practice]]s the authors hope to get rid of them: "Authors MUST NOT implement bugs. If bugs are introduced in code, they MUST be clearly documented."
*{{Sum RFC|9226|ref=yes|refnotes=no}}
::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).

==={{visible anchor|2023}}===
*{{Sum RFC|9401|ref=yes|refnotes=no}}
::As is customary in [[light novel]]s, a 'death flag' indicates the increased likelihood of a swift demise of the character. Transferred to [[Transmission Control Protocol|TCP]], the DTH flag in the [[header (computing)|packet header]] could lead to smoother and more attractive session narratives.
*{{Sum RFC|9402|ref=yes|refnotes=no}}
::Finally, a formalized way (with a [[Augmented Backus–Naur form|ABNF]] [[grammar]] description) to properly describe the interaction between [[cat]]s and [[container]]s, including the occasional ball of [[yarn]].
*{{Sum RFC|9405|ref=yes|refnotes=no}}
::The AI Sarcasm Detection Protocol (ASDP) is a [[Software framework|framework]] for detecting [[sarcasm]] in [[Artificial intelligence|AI systems]] (written with the help of [[ChatGPT]]). Detecting sarcasm may help improve AI - human intercommunication.

==={{visible anchor|2024}}===
*{{Sum RFC|9564|ref=yes|refnotes=no}}
::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.

==={{visible anchor|2025}}===
*{{Sum RFC|9759|ref=yes|refnotes=no}}
::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 ==
*{{Sum RFC|439|ref=yes}}
::Transcript of a talk of the [[schizophrenic]] [[chatbot]] [[PARRY]] with the [[computer simulation|computer simulated]] [[psychiatrist]] [[ELIZA]] (a.k.a. 'The Doctor') which both fail the [[Turing test]] with flying colours.
*{{Sum RFC|527|ref=yes}}
::A very '[[Advanced Research Projects Agency|ARPA]]-ish' parody of [[Lewis Caroll]]'s [[nonsense poem]] '[[Jabberwocky]]'.
*{{Sum RFC|968|ref=yes}}
::A [[poem]] that discusses problems that arise, and debugging techniques used, in bringing a new network into operation. It shows that [[Array index|array indexing]] is problematic since the olden days.
*{{Sum RFC|1882|ref=yes}}
::A parody of the [[Christmas carol]] '[[The Twelve Days of Christmas (song)|The Twelve Days of Christmas]]', where computer problems pile up and the IT staff is swamped, like on a regular day.
*{{Sum RFC|2410|ref=yes}}
::Introducing the [[Null function|NULL encryption algorithm]], [[Mathematics|mathematically]] defined as the [[Identity function]]: {{Math|1=''NULL''(''b'') {{=}} ''I''(''b'') {{=}} ''b''}}, 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.<ref name=":0">{{cite web|url=//www.rfc-editor.org/rfc-editor/instructions2authors.txt |title=Instructions to Request for Comments (RFC) Authors |access-date=2012-03-18 |url-status=dead |archive-url=https://web.archive.org/web/20120327234338/http://www.rfc-editor.org/rfc-editor/instructions2authors.txt |archive-date=2012-03-27 }}</ref><ref>{{cite web|url=//www.rfc-editor.org/rfcfaq.html#april |title=IETF RFC-Editor FAQ, Q20: How can I submit an April 1st RFC? |publisher=Rfc-editor.org |date=2011-07-21 |access-date=2012-03-18}}</ref> 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."<ref name=":0" />

== References==
{{Reflist}}

==Further reading==
* [//www.rfc-editor.org/ RFC Editor home page] – hosts individual RFCs

== External links ==
* {{cite news | title = Yet Another Foolish Network Protocol| work = Network World | url = https://www2.cio.co.nz/article/129195/yet_another_foolish_network_protocol/| first = Carolyn Duffy | last = Marsan | date = April 1, 2005 | postscript = none }} – on RFC 3751 and April Fools' Day RFCs in general.<!-- also at http://findarticles.com/p/articles/mi_qa3649/is_200503/ai_n13591764 -->
* {{cite book |title=The Complete April Fools' Day RFCs |last= Limoncelli |first= Thomas&nbsp;A.|author2=Peter H. Salus |year= 2007|publisher= Peer-to-Peer Communications|isbn= 978-1-57398-042-5}}

[[Category:April Fools' Day jokes]]
[[Category:Request for Comments]]
[[Category:Computer humour]]
[[Category:Hacker culture]]