Telnet randomly-lose option
An April 1st joke proposing a Telnet option to lose data randomly
Crispin, M.R., "Telnet randomly-lose option", RFC 748, DOI 10.17487/RFC0748, April 1978, <https://www.rfc-editor.org/info/rfc748>.
@misc{rfc748,
series = {Request for Comments},
number = 748,
howpublished = {RFC 748},
publisher = {RFC Editor},
doi = {10.17487/RFC0748},
url = {https://www.rfc-editor.org/info/rfc748},
author = {M.R. Crispin},
title = {{Telnet randomly-lose option}},
pagetotal = 2,
year = 1978,
month = apr,
} RFC text
NWG/RFC# 748 MRC 1-APR-78 44125
Telnet Randomly-Lose Option
Network Working Group M. Crispin
Request for Comments 748 SU-AI
NIC 44125 1 April 1978
TELNET RANDOMLY-LOSE Option
1. Command name and code.
RANDOMLY-LOSE 256
2. Command meanings.
IAC WILL RANDOMLY-LOSE
The sender of this command REQUESTS permission to, or confirms
that it will, randomly lose.
IAC WON'T RANDOMLY-LOSE
The sender of this command REFUSES to randomly lose.
IAC DO RANDOMLY-LOSE
The sender of this command REQUESTS that the receiver, or grants
the receiver permission to, randomly lose.
IAC DON'T RANDOMLY-LOSE
The command sender DEMANDS that the receiver not randomly lose.
3. Default.
WON'T RANDOMLY-LOSE
DON'T RANDOMLY-LOSE
i.e., random lossage will not happen.
4. Motivation for the option.
Several hosts appear to provide random lossage, such as system
crashes, lost data, incorrectly functioning programs, etc., as part
of their services. These services are often undocumented and are in
general quite confusing to the novice user. A general means is
needed to allow the user to disable these features.
NWG/RFC# 748 MRC 1-APR-78 44125
Telnet Randomly-Lose Option
5. Description of the option.
The normal mode does not allow random lossage; therefore the system
is not allowed to crash, mung user files, etc. If the server wants
to provide random lossage, it must first ask for permission from the
user by sending IAC WILL RANDOMLY-LOSE.
If the user wants to permit the server to randomly lose, it replys
with IAC DO RANDOMLY-LOSE. Otherwise it sends IAC DONT
RANDOMLY-LOSE, and the server is forbidden from randomly losing.
Alternatively, the user could request the server to randomly lose, by
sending IAC DO RANDOMLY-LOSE, and the server will either reply with
IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
random lossage (garbaging disk files is recommended for an initial
implementation). Or, it could send IAC WONT RANDOMLY-LOSE, meaning
that it insists upon being reliable.
Since this is implemented as a TELNET option, it is expected that
servers which do not implement this option will not randomly lose;
ie, they will provide 100% reliable uptime.
AI ELI5
On this page
§1A Proposal for Managed Unreliability
RFC 748 is an April 1st joke published on 1 April 1978. It proposes a new TELNET option called RANDOMLY-LOSE that lets systems request and grant permission to randomly lose data.
The RFC opens by observing that several ARPANET hosts appeared to provide "random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services." These services were often undocumented and confusing to users. The joke is that these failures should be formalized, negotiated, and made official.
This is an April Fools' joke from 1978. It pretends that randomly breaking things should be an official feature of computer networks that you can turn on or off.
§2The RANDOMLY-LOSE Option
The option uses TELNET's standard negotiation protocol. A server sends IAC WILL RANDOMLY-LOSE to request permission to randomly lose data, and the client replies with IAC DO RANDOMLY-LOSE to grant permission or IAC DON'T RANDOMLY-LOSE to forbid it.
Alternatively, a client can request that the server randomly lose by sending IAC DO RANDOMLY-LOSE, and the server replies with IAC WILL RANDOMLY-LOSE (agreeing) or IAC WON'T RANDOMLY-LOSE (insisting on being reliable). The default is WON'T and DON'T, meaning no random loss unless negotiated.
The joke follows real TELNET option rules: one side says "may I randomly lose data?" and the other side says yes or no.
§3The Satire
The real point of the joke is that many ARPANET hosts in 1978 were unreliable: they crashed, lost data, or behaved incorrectly without warning or good reason. Some of these failures were due to bugs; others were due to hardware limitations or operating system quirks. Users had no way to predict or disable these failures.
By proposing that random lossage be made an official, negotiated TELNET option, the RFC humorously suggests that chaos should be formalized and controllable—which reveals the absurdity of leaving it undocumented and unpredictable. It also gently mocks the idea that any system would openly admit to providing undocumented failure modes.
The real joke is that computers did lose data and crash back then, and nobody documented it or controlled it. The RFC pretends to fix that by making it an official feature you can agree to, which is obviously silly.
§4Implications
RFC 748 notes that servers which do not implement this option will be assumed to provide 100% reliable uptime. The joke is layered: not only is the option absurd, but the claim that any system not advertising RANDOMLY-LOSE is fully reliable is obviously false.
The RFC remained a joke. No TELNET implementation adopted the option, and no systems formally advertised random lossage. However, the document is valuable as a window into 1970s computer culture: it shows how frustrating and unreliable early networking systems were, and how the community responded with humor when faced with intractable problems.
If you do not say you will randomly lose, people assume you will not. The joke is that was obviously not true in the 1970s; servers broke all the time without asking.