Retrotelnetrfcapril-foolsinternet-historynetworking
RFC 748, an April 1, 1978 Telnet Spec, Made Servers Ask Your Permission Before Randomly Losing Your Files
Mark Crispin's RFC 748, dated April 1, 1978, defined a Telnet option numbered 256 that a server had to negotiate with you before it was allowed to crash, garble files or otherwise lose at random.
The whole document fits on about one page. Its header reads “M. Crispin, SU-AI, NIC 44125,” with the date April 1, 1978, and it starts from a complaint every terminal user of the era would recognize. “Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services,” Crispin wrote. “These services are often undocumented and are in general quite confusing to the novice user.”
His fix was to make the lossage official. Telnet already let the two ends of a connection agree on features through a small set of commands. RFC 854 defines them as single bytes: IAC (255) means “interpret as command,” then WILL (251), WON’T (252), DO (253) or DON’T (254), then the option’s number. RFC 748 slots random lossage into that machinery like any other feature.
The default is the safe one: “WON’T RANDOMLY-LOSE” and “DON’T RANDOMLY-LOSE,” which the spec glosses as “random lossage will not happen.” Section 5 lays out the rules. “If the server wants to provide random lossage, it must first ask for permission from the user by sending IAC WILL RANDOMLY-LOSE.” The user grants it with IAC DO. The spec even offers an implementation tip: “garbaging disk files is recommended for an initial implementation.”
Then there’s the number. RFC 748 assigns RANDOMLY-LOSE the code 256. Telnet carries an option code in one byte, so the real list stops at 255. RFC 861, from Jon Postel and Joyce Reynolds in May 1983, spent that last slot on a way out: “Eventually, a 257th TELNET option will be needed,” it says, and option 255, Extended-Options-List, would “extend the option list for another 256 options.” IANA’s Telnet options registry still ends at “255 Extended-Options-List,” with no 256 in sight.
Crispin’s joke didn’t stay alone for long. Eleven years later, B. Miller of CMU-NetDev published RFC 1097, “TELNET SUBLIMINAL-MESSAGE Option,” also dated April 1, and gave it the number 257. In 1998 came RFC 2324 and its “418 I’m a teapot” error, whose response body “MAY be short and stout.” Wikipedia’s list of April Fools’ RFCs opens with RFC 748 in 1978 and notes that “for a long time it was specially marked in the RFC index with ‘note date of issue’.”
The author went on to more serious protocol work. Mark Crispin wrote IMAP, the protocol most email apps still use to read mail on a server; RFC 3501, the IMAP4rev1 spec from March 2003, carries his name from the University of Washington.
Opt-in failure keeps coming back as a serious idea. Chaos engineering tools that kill servers on purpose in production run on a version of Crispin’s handshake: the team agrees to the lossage first, in writing, and the default stays off. The difference is that today’s version asks permission in a config file instead of over a Telnet session. What nobody has ever answered is how many 1978 hosts would have honestly sent IAC WILL RANDOMLY-LOSE if the option had been real.