RFC 1149: The April Fools' Document That Exposes What RFC Status Means
Read RFC 1149 as a historical experiment, not an Internet standard, and trace how its humor, metadata, and later updates are officially recorded.
RFC 1149 is famous for describing the transmission of IP datagrams on avian carriers. It is also a useful case study in a less amusing technical point: publication in the RFC series does not automatically make a document an Internet Standard. The RFC Editor labels RFC 1149 “Experimental” and “humor,” while the document itself says its method is experimental and not a recommended standard. That status is part of the historical record, not a footnote to ignore.
David Waitzman’s memo was published on April 1, 1990. It describes carrying a printed datagram by bird, with an MTU measured in milligrams and packet loss caused by carrier loss or storms. The jokes borrow the vocabulary of real protocol engineering: encapsulation, service priority, retries, logs, and security considerations. Their specificity is why the document remains memorable, but the RFC Editor’s metadata and the text’s own status statement make its intent clear.
RFC is a publication series, not a single standards label
The RFC series includes documents with different purposes and statuses. A reader needs to inspect each document’s status and stream rather than infer authority from the RFC number. RFC 1149 was published through the Independent Submission Stream; its RFC Editor record categorizes it as humor and experimental. It is not a standards-track protocol for production networking.
This distinction matters beyond April Fools’ documents. A published RFC might describe a proposal, an experiment, an informational memo, or a standards-track specification. The cover page, status language, stream, and later document history establish what process produced it. A citation that says only “RFC 1149 is an Internet standard” is false even though RFC 1149 is an official RFC Editor publication.
RFC 5741 explains why these labels must be read together: publication in the RFC series does not mean the same review path was followed for every document. Standards Track work comes through the IETF standards process, while other RFC streams have their own review and publication procedures. The stream identifies the document’s origin; the category describes its publication status; the status-of-memo text explains whether it is intended for standards, experimental, informational, or historical use. These are related metadata, but they are not interchangeable.
For RFC 1149, the most decisive evidence is in the memo itself: it calls the method experimental and explicitly says it is not a recommended standard. The RFC Editor’s current record adds the humor classification and Independent Stream attribution. Read together, those signals explain how a carefully formatted RFC can be an official archival publication and still be satire rather than a deployment recommendation. “Experimental” is not a claim that the method passed an operational trial; the document’s own framing and technical jokes make clear that it is a parody of protocol specifications.
The joke follows the shape of real IP constraints
The memo maps packet terminology onto physical delivery. It notes that latency is high, throughput is low, and the available bandwidth is constrained by how much data the carrier can physically transport. It describes variable MTU, best-effort delivery, retransmission, and the possibility that a carrier fails to arrive. These are not measured performance claims about a deployed service; they are humorous analogies in an explicitly experimental memo.
The most technically useful reading is therefore comparative. A packet network has finite link capacity, transmission delay, loss, and ordering questions. Any store-and-forward medium must represent a datagram, carry it, and reconstruct it at the receiver. RFC 1149 turns those design questions into a memorable thought experiment without claiming that biological transport is practical or recommended.
The RFC family extends the original joke
RFC 2549, published in 1999, adds quality-of-service language to the avian-carrier premise. RFC 6214, published in 2011, adapts the joke to IPv6. The RFC Editor records these as updates to RFC 1149. Their existence demonstrates continuity of the satire, not an operational rollout of a new standard. Read the family together to see how technical conventions can be imitated and gently critiqued.
The publication metadata can also change after publication. RFC 2549’s Datatracker history, for example, records a metadata update in 2026 that adds keywords about avian carriers, April Fools, and QoS. This is a cataloging change, not a protocol revision. Document histories distinguish changes to the record from changes to the technical text.
That distinction is useful when the record appears newer than the document. RFC 2549’s published text dates to April 1, 1999, while its catalog history now includes later changes to author fields, stream data, and search keywords. The page can improve discovery and correct bibliographic details without replacing the original memo. The Updates relation is different again: it is part of how the RFC series links one document to another, not evidence that a later RFC converted the older document into a Standards Track specification. In this family, the linked records preserve the joke’s chronology and publication status rather than certify a working protocol.
A reliable way to cite an RFC
When using any RFC as evidence, check the RFC Editor record and the document itself:
- Confirm the title, authors, publication date, and number.
- Read the status section and identify the stream or standards process.
- Follow the “Updated by” or “Obsoleted by” links before describing it as current.
- Separate metadata edits from revisions to the document.
- Quote the document’s actual recommendation level, not its familiar nickname.
For RFC 1149, these checks lead to a precise description: it is an April 1, 1990 experimental humorous memo, later extended by RFC 2549 and adapted to IPv6 by RFC 6214. Calling it an Internet Standard confuses inclusion in the RFC series with standards approval.
The document’s lasting value is cultural as well as technical. It gives engineers a compact vocabulary for discussing latency, throughput, MTU, loss, and quality of service, while reminding readers that a protocol document’s authority comes from its status and process, not from a number that looks official.
Related:
- How to Read and Understand Old Internet RFCs
- How to Research a Tech History Topic Using Primary Sources
Sources: