RFC | A traditional series of April Fools‘ RFCs

本文链接：https://blog.csdn.net/u013669912/article/details/146514804

注：机翻，未校。

Requests For Comments

请求意见书

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.

请求意见书（Request for Comments，简称 RFC）是在互联网治理的背景下，由互联网工程任务组（Internet Engineering Task Force，简称 IETF）和互联网协会（Internet Society，简称 ISOC）发布的文件，通常描述适用于互联网及其连接系统运行的方法、行为、研究或创新。

Requests For Comments, or RFCs, form the basis of the Internet’s technical documentation.
Requests For Comments（RFC）构成了 Internet 技术文档的基础。
Conceptionally, the Internet is best thought of as a layered series of protocols, each of which is documented by one or more RFCs.
从概念上讲，最好将 Internet 视为一系列分层协议，每个协议都由一个或多个 RFC 记录。
Once issued, RFCs do not change.
RFC 一经发布，便不会更改。
Protocol revisions are documented by issuing new RFCs.
通过发布新的 RFC 来记录协议修订。
The older RFCs are still available, but are said to be obsoleted by the newer RFCs.
旧的 RFC 仍然可以查阅，但已被新的 RFC 取代。
Not all RFCs document protocols; some are simply for discussion or informational purposes, and a traditional series of April Fools’ RFCs can be distinguished by their date.
并非所有 RFC 都记录协议；有些只是为了讨论或提供信息，而传统的愚人节 RFC 系列可以通过它们的日期来区分。

Non-RFC IETF humor

非 RFC 的 IETF 幽默

An announcement on the IETF list [2] about the appointment of the Sesame Street character Bert[3] as member of the IAB appears to have been the April Fools’ Day 2006 stunt.

IETF 邮件列表上的一则公告 [2]，宣布任命《芝麻街》角色 Bert [3] 为互联网架构委员会（IAB）成员，似乎是 2006 年愚人节的恶搞。

“Sesame Street” 是一档非常著名的美国儿童教育电视节目，其中有许多经典的角色。

Bert 是其中一个非常受欢迎的角色，他和他的好朋友 Ernie 组成了一个经典的搭档。

两人性格截然相反，但关系非常好。Bert 总是试图保持秩序和整洁，而 Ernie 则喜欢搞恶作剧和打破规则。他们经常会因为一些小事发生争执，但最终总能和解。这些互动不仅有趣，还能教给孩子们如何处理冲突和理解不同的性格。

“A traditional series of April Fools’ RFCs”

“传统的愚人节 RFC 系列”
Almost every 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”.

自 1989 年以来，几乎每年的 4 月 1 日（愚人节），互联网 RFC 编辑都会发布一份或多份幽默的请求意见书（RFC），这一传统始于 1973 年 6 月发布的名为 ARPAWOCKY 的 RFC，它是对刘易斯・卡罗尔（Lewis Carroll）的荒诞诗《Jabberwocky》的恶搞。

著名的愚人节 RFC 例子有：

RFC 1149，提出用鸽子传输 IP 数据包。
RFC 2324，关于咖啡壶控制协议。
RFC 3514，涉及邪恶比特标识。

尽管这些文档是玩笑性质，但有时能引发人们对真实技术问题的思考与讨论。

Submission of April Fools’ Day RFCs

愚人节 RFC 的提交
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.

RFC 编辑接受来自公众的格式正确的愚人节 RFC 提交，并会在收到后至少两周内考虑在同一年内发布。

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.”

在 RFC 作者的指导备忘录中特别提到了发布愚人节 RFC 的做法，并附上了一段半开玩笑的话：“请注意，在过去的几年里，RFC 编辑有时会在 4 月 1 日发布一些严肃的文件。那些无法通过阅读文本区分讽刺的读者，或许可以在市场营销领域找到未来。”

The following list also includes humorous RFCs published on other dates.

以下列表还包括在其他日期发布的幽默 RFC。

List of April Fools’ Day RFCs

愚人节 RFC 列表
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”.

这是对 TCP/IP 文档风格的恶搞。很长时间以来，它在 RFC 索引中被特别标注为 “注意发布日期”。

Updated by RFC 2549 in 1999; see below. Describes protocol for transmitting IP packets by homing pigeon.

1999 年由 RFC 2549 更新；见下文。描述了通过信鸽传输 IP 数据包的协议。

In 2001, RFC 1149 was actually implemented by members of the Bergen Linux User Group.

2001 年，RFC 1149 实际上被卑尔根 Linux 用户组的成员实现了。

See also RFC 6214, as noted below. Describes the adaptation of RFC 1149 for IPv6.

参见下文提到的 RFC 6214。描述了将 RFC 1149 适配到 IPv6 的情况。

See also: Evil bit.

参见：邪恶位。

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.

值得注意的是，它包含了 PDP - 10 汇编语言代码，尽管制造商在 22 年前就停止生产 PDP - 10，但与其他许多提议不同，它是技术上可行的。

RFC Draft: “IP over Burrito Carriers”
RFC 草案：《IP over Burrito Carriers》

A delicious internet protocol recipe, to communicate while eating.

一份美味的互联网协议食谱，用于在进食时进行通信。

An April 1st RFC was not published this year, but an [announcement on the IETF list](https://mailarchive.ietf.org/arch/msg/rfc - interest/xaHiBCRy26Q9V4 - 6xL2aHtqY0e8/) about the appointment of the Sesame Street character Bert as member of the IAB appears to have been the April Fools’ Day 2006 stunt.

2006 年 4 月 1 日没有发布 RFC，但 IETF 邮件列表上关于任命芝麻街角色 Bert 为 IAB 成员的公告似乎是 2006 年愚人节的恶搞。

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

由作者在撰写 RFC 的过程中在 Facebook 上实现。

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’).

增强了 RFC 作者以更非正式的方式传达意图和目的的能力，使用（非）指令性关键词，例如：“MUST (BUT WE KNOW YOU WON’T)”（当你知道会被忽略，但为了显得道德上更优越）和 “REALLY SHOULD NOT”（当预期到 “男孩就是男孩” 时）。

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.

当能够在互联网上以超光速发送数据包时，它们可能会在发送之前就被接收（由于时间反转），这将对当今许多协议产生重大影响。如果速度足够快（以及相应的负时间偏移），一次完整的通信可能在开始之前就已经完成。该 RFC 审查了这些协议的设计原则，以防止未来通信的中断。很可能，我们昨天就应该开始升级它们了。

Updates 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.

为能够冲泡茶的咖啡机更新。还定义了 HTTP 响应代码 418 I’m a Teapot，供茶壶在无法冲泡咖啡时使用。

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

尽管通常不受欢迎，但 X509 数字证书的私钥可能已经与第三方共享，无论是为了合法拦截还是其他原因。现在可以通过一个新的证书扩展来通知用户这一事实，指定布尔值 ext - KeyUsage。当值为 ‘true’ 时，表示私钥已被共享；当值为 ‘false’ 时，签名者不对是否发生共享发表评论。

Green IT has become increasingly important. In a [win - win](https://everything.explained.today/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](https://everything.explained.today/Wi - Fi/) or by pidgeons will help them escape their torturous routine of assembly and disassembly, and being shot through dark fibers and copper cables all the time.

绿色 IT 越来越重要。为了数据包和环境的双赢，本 RFC 定义了一种方法，允许数据包通过空气路由，尽可能多地获取阳光和新鲜空气。通过 Wi - Fi 或信鸽发送数据包，将帮助它们摆脱组装和拆卸的痛苦过程，以及一直被射入黑暗的光纤和铜缆中的命运。

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 - up s if the audio channel is muted.

类似于已被废弃的 ICMP 源抑制方法，它重用了该数据包的 “Type” 字段（4），以比 ECN 更明确的方式告诉发送方闭嘴。负责该流量的用户必须通过文本到语音的方式，或者如果音频通道被静音，则通过弹出窗口来了解 RECN 消息的内容。

An April 1st RFC was not published this year.

那年 4 月 1 日没有发布 RFC。

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.

采用一种相当数学的方法，以不同于传统的方式使用 128 位 IPv6 地址空间，最终得出复数地址。例如，你可以使用一个复数地址的虚部（实部为极坐标）来到达圣诞老人。它还提议为使用 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.

随着互联网架构委员会打算放宽对新协议或扩展协议与 IPv4 的兼容性要求，本 RFC 通过为所有 IPv4 数据包设置邪恶位来促进 IPv6 的采用，确保双栈主机将优先选择 IPv6，快乐眼球算法也是如此。为了保持 IPv4 和 IPv6 之间的功能等价性，应在 IPv6 头部中包含 “安全标志”。高级安全选项可以在新的逐跳选项头部中指定。

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 avian carriers.

最精美的 ASCII 艺术形式。描绘并注释了果蝠、尼斯湖水怪、一些基础的包豪斯元素，甚至一群飞行载体。

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!

这是一声发自内心的呐喊，呼吁结束在 IP 层面上的数据包歧视，即使在当今时代，数据包仍然会因为颜色、长度、年龄等因素，甚至 IP 版本而被提前终止！

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.

提议使用 128 位 Unicode 来促进 IPv6 的国际化，因为当前 Unicode 实现的 1,114,112 个代码点被认为不足以满足未来需求。IPv6 地址可以用一个单独的 U + 128 字形表示，以减轻网络管理员的视觉压力。

If implemented, it would obsolete, because “[i] t 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.

一种类似于 HTTP/1.1 的 “响应 / 请求” 协议，但客户端向服务器发送响应（例如：“Hello World. My payload includes a trailing CRLF.”），服务器则以请求（例如：GET /hello.txt）作为回答，就像在 Jeopardy! 游戏中一样。超文本双重危险协议（HTJ2P）（在附录 A 中描述）再次反转了 HTJP 的语义。

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.

作者认为，DNS（通过 DNSSEC 加密）最适合在全球范围内可靠地提供信息，以帮助维护 CPE（以及其他设备）的高质量体验。通过定义四种新的 DNS RR 类型（密码、信用卡号、社会保障号和一个 SSN 指针记录），他们希望实现端到端的全面网络管理。

A proposal to use [UTF - 8](https://everything.explained.today/UTF - 8/) to obfuscate (and help replace) textual IP address es, to coerce a small minority of people to use the DNS instead of sticking to (and mixing up) plain IP addresses.

提议使用 UTF - 8 来混淆（并帮助替换）文本形式的 IP 地址，以促使少数人使用 DNS，而不是坚持使用（并混淆）纯 IP 地址。

Dismisses with the notion that considering time travel for [faster - than - light](https://everything.explained.today/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 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.

驳斥了将超光速数据包传输视为 “有趣” 但不可能的概念。相反，它关注现实生活中的量子纠缠与数据包往返时间的关系，这（取决于观察者）可能达到零。这可能会在多个协议中引发混乱，应该在事情崩溃之前 “及时” 修复。

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 s and may even resort to traffic imprisonment. By the way: if you are interested in joining the Protocol Police, contact your localhost.

由于互联网工程任务组声称它 “非协议警察”，因此在这里正式设立。它负责监管 RFC 系列所规定的各种协议定义，并确保遵守这些协议。他们被授权访问封闭花园，甚至可以采取流量监禁措施。顺便说一句：如果你有兴趣加入协议警察，请联系你的 localhost。

Discourages the practice of introducing 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.”
不鼓励引入软件缺陷，以降低成本并减少安全影响。通过引入一些最佳当前实践，作者希望消除这些问题：“作者不得在代码中引入缺陷。如果引入了缺陷，必须明确记录。”

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).

通过将十六进制的 0 - 9 和 A - F 字母表替换为两个八进制范围：0 - 7 和字母 ‘cjzwfsbv’（以一种位运算优雅的方式表示值 8 - 15），可以避免十六进制表示数字时的已知问题。

As is customary in light novel s, 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.

在轻小说中，一个 “死亡标志” 表示角色迅速死亡的可能性增加。将其转移到 TCP 中，数据包头部中的 DTH 标志可能导致更顺畅和更具吸引力的会话叙事。

Finally, a formalized way (with an ABNF grammar description) to properly describe the interaction between cats and container s, including the occasional ball of yarn.

最后，以一种正式化的方式（使用 ABNF 语法描述）来正确描述猫与容器之间的互动，包括偶尔的毛线球。

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.

人工智能讽刺检测协议（ASDP）是一个用于在人工智能系统中检测讽刺的框架（在 ChatGPT 的帮助下编写）。检测讽刺可能有助于改善人工智能与人类之间的交流。

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.

人工智能（AI）的最新进展，例如大型语言模型，使得设计用于互联网的超光速协议（FLIP）成为可能。FLIP 通过使用 AI 在接收端预测数据包到达之前的数据包，从而避免拥塞、增强安全性，并在互联网上更快地传输数据包。本文档描述了该协议及其各种封装方式，并考虑了一些操作因素。

Other humorous RFCs

其他幽默的 RFC
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 colors.

一份记录了精神分裂症聊天机器人 PARRY 与计算机模拟的精神病学家 ELIZA（别名 “医生”）之间对话的记录，它们都以出色的表现未能通过图灵测试。

A very ‘ARPA-ish’ parody of Lewis Caroll’s nonsense poem ‘Jabberwocky’.

一个非常具有 “ARPA - 风格” 的对刘易斯・卡罗尔的荒诞诗 “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.

对圣诞颂歌 “The Twelve Days of Christmas” 的恶搞，其中计算机问题堆积如山，IT 人员忙得不可开交，就像平常一样。

Introducing the NULL encryption algorithm, mathematically defined as the Identity function: $\text {NULL}(x)=x$ , provides the means for Encapsulating Security Payload to provide authentication and integrity, but without confidentiality.

引入了 NULL 加密算法，从数学上定义为恒等函数： $\text {NULL}(x)=x$ ，它为封装安全载荷提供了认证和完整性的手段，但不提供保密性。

External links

News: Yet Another Foolish Network Protocol. Network World. Carolyn Duffy. Marsan. April 1, 2005. none. – on RFC 3751 and April Fools’ Day RFCs in general.
Book: Limoncelli, Thomas A… The Complete April Fools’ Day RFCs. Peter H. Salus. 2007. Peer - to - Peer Communications. 978 - 1 - 57398 - 042 - 5.

Notes and References

Web site: RFC 1149 implemented . Blug.linux.no. 2012 - 03 - 18. https://web.archive.org/web/20111004221306/http://www.blug.linux.no/rfc1149/. 2011 - 10 - 04. dead.
draft - lohsen - ip - burrito - 00. IP over Burrito Carriers. M. Schulze. W. Lohsen. 1 April 2005. Internet Engineering Task Force.
Web site: [//tools.ietf.org/html/rfc5514#ref - IPv6overFacebook IPv6 over the Facebook Social Network]. E. Vyncke.
[ hey, guys, where 1 april 2016 RFC. Ups… ](https://mailarchive.ietf.org/arch/msg/rfc - interest/xaHiBCRy26Q9V4 - 6xL2aHtqY0e8/). 2 April 2016. rfc - i. Flanagan. Heather.
Web site: [//www.rfc - editor.org/rfc - editor/instructions2authors.txt Instructions to Request for Comments (RFC) Authors ]. 2012 - 03 - 18. dead. https://web.archive.org/web/20120327234338/http://www.rfc - editor.org/rfc - editor/instructions2authors.txt. 2012 - 03 - 27.
Web site: [//www.rfc - editor.org/rfcfaq.html#april IETF RFC - Editor FAQ, Q20: How can I submit an April 1st RFC? ]. Rfc - editor.org. 2011 - 07 - 21. 2012 - 03 - 18.

List of April 1st RFCs

RFC 748—TELNET RANDOMLY-LOSE option. M.R. Crispin. 1 April 1978. A parody of the TCP/IP documentation style. Due to some people taking it seriously, for a long time it was specially marked in the RFC index with “note date of issue”.
RFC 1097—TELNET SUBLIMINAL-MESSAGE option. B. Miller. 1 April 1989.
RFC 1149—Standard for the transmission of IP datagrams on Avian Carriers. D. Waitzman. 1 April 1990

. Updated by RFC 2549; see below. A deadpan skewering of standards-document legalese, describing protocols for transmitting Internet data packets by homing pigeon.
- In 2001, RFC 1149 was actually implemented [1] by members of the Bergen (Norway) Linux User Group.
RFC 1216—Gigabit Network Economics and Paradigm Shifts. Poorer Richard, Prof. Kynikos. 1 April 1991.
RFC 1217—Memo from the Consortium for Slow Commotion Research (CSCR). Vint Cerf. 1 April 1991.
RFC 1313—Today’s Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. 1 April 1992. Certain portions of this RFC are obsolete: Doppler shift while flying on the Concorde is no longer a problem - the Concorde has retired from service.
RFC 1437—The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. 1 April 1993.
RFC 1438—Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. 1 April 1993.
RFC 1605—SONET to Sonnet Translation. William Shakespeare. 1 April 1994.
RFC 1606—A Historical Perspective On The Usage Of IP Version 9. J. Onions. 1 April 1994.
RFC 1607—A VIEW FROM THE 21ST CENTURY. Vint Cerf. 1 April 1994.
RFC 1776—The Address is the Message. Steve Crocker. 1 April 1995. Without content, would we need information security?
RFC 1924—A Compact Representation of IPv6 Addresses. R. Elz. 1 April 1996.
RFC 1925—The Twelve Networking Truths. R. Callon. 1 April 1996.
RFC 1926—An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. 1 April 1996.
RFC 1927—Suggested Additional MIME Types for Associating Documents. C. Rogers. 1 April 1996.
RFC 2100—The Naming of Hosts. J. Ashworth. 1 April 1997.
RFC 2321—RITA – The Reliable Internetwork Troubleshooting Agent. A. Bressen. 1 April 1998.
RFC 2322—Management of IP numbers by peg-dhcp. K. van den Hout et al. 1 April 1998.
RFC 2323—IETF Identification and Security Guidelines. A. Ramos. 1 April 1998.
RFC 2324—Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. 1 April 1998.
RFC 2325—Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2. M. Slavitch. 1 April 1998.
RFC 2549—IP over Avian Carriers with Quality of Service. D. Waitzman. 1 April 1999. Updates RFC 1149, listed above.
RFC 2550—Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. 1 April 1999.
RFC 2551—The Roman Standards Process – Revision III. S. Bradner. 1 April 1999.
RFC 2795—The Infinite Monkey Protocol Suite (IMPS). S. Christey. 1 April 2000.
RFC 3091—Pi Digit Generation Protocol. H. Kennedy. 1 April 2001.
RFC 3092—Etymology of “Foo”. D. Eastlake 3rd, C. Manros, E. Raymond. 1 April 2001.
RFC 3093—Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. 1 April 2001.
RFC 3251—Electricity over IP. B. Rajagopalan. 1 April 2002.
RFC 3252—*B*inary *L*exical *O*ctet *A*d-hoc *T*ransport. H. Kennedy. 1 April 2002.
RFC 3514—The Security Flag in the IPv4 Header (Evil Bit). S. Bellovin. 1 April 2003.
RFC 3751—Omniscience Protocol Requirements. S. Bradner 1 April 2004.
RFC 4041—Requirements for Morality Sections in Routing Area Drafts. A. Farrel. 1 April 2005.
RFC 4042—UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. 1 April 2005. Notable for containing PDP-10 assembly language code nearly 22 years after the PDP-10 architecture was canceled by its manufacturer.
RFC 4824—The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS). Jogi Hofmueller, Aaron Bachmann, IOhannes zmoelnig. 1 April 2007.
RFC 5241—Naming Rights in IETF Protocols. A. Falk, S. Bradner 1 April 2008.
RFC 5242—A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand 1 April 2008.
RFC 5513—IANA Considerations for Three Letter Acronyms. A. Farrel 1 April 2009.
RFC 5514—IPv6 over Social Networks. E. Vyncke 1 April 2009, implemented on Facebook Ipv6 over Facebook.

Other humorous RFCs

RFC 439—PARRY encounters the DOCTOR. V. Cerf. 21 January 1972.
RFC 527—ARPAWOCKY. R. Merryman, UCSD. 22 June 1973.
RFC 968—Twas the night before start-up. V.G. Cerf, 1 December 1985.
RFC 1882—The 12-Days of Technology Before Christmas. B. Hancock. December 1995.