Telnet subliminal-message option
An April Fools' joke about hiding secret messages in Telnet sessions.
Miller, B., "Telnet subliminal-message option", RFC 1097, DOI 10.17487/RFC1097, April 1989, <https://www.rfc-editor.org/info/rfc1097>.
@misc{rfc1097,
series = {Request for Comments},
number = 1097,
howpublished = {RFC 1097},
publisher = {RFC Editor},
doi = {10.17487/RFC1097},
url = {https://www.rfc-editor.org/info/rfc1097},
author = {B. Miller},
title = {{Telnet subliminal-message option}},
pagetotal = 3,
year = 1989,
month = apr,
} RFC text
Contents
Network Working Group B. Miller
Request for Comments: 1097 CMU-NetDev
1 April 1989
TELNET SUBLIMINAL-MESSAGE Option
Status of this Memo
This RFC specifies a standard for the Internet community. Hosts on
the Internet that display subliminal messages within the Telnet
protocol are expected to adopt and implement this standard.
Distribution of this memo is unlimited.
1. Command name and code.
SUBLIMINAL-MESSAGE 257
2. Command meanings.
IAC WILL SUBLIMINAL-MESSAGE
The sender of this command REQUESTS permission to, or confirms
that it will, display subliminal messages.
IAC WONT SUBLIMINAL-MESSAGE
The sender of this command REFUSES to display subliminal messages.
IAC DO SUBLIMINAL-MESSAGE
The sender of this command REQUESTS that the receiver, or grants
the receiver permission to, display subliminal messages.
IAC DONT SUBLIMINAL-MESSAGE
The sender of this command DEMANDS that the receiver not display
subliminal messages.
IAC SB SUBLIMINAL-MESSAGE <16-bit value> <16-bit value> <string> IAC
SE
The sender specifies a message to be subliminaly displayed by the
remote host. If the client has agreed (via the standard WILL WONT
DO DONT mechanism) to display subliminal messages, it must accept
this subnegotiation and attempt to display the message string on
the users console for the specified duration and continue to do so
at fixed intervals until another SUBLIMINAL-MESSAGE subnegotiation
is received. The position and rendering of the message of
implementation dependent.
The first 16-bit value specifies the duration of the message in
milliseconds. It is sent MSB first. The second 16-bit value
specifies the frequency with which the message is displayed. It
represents the number of seconds between displays and is also sent
MSB first. The final parameter is the message itself.
The syntax for this subnegotiation is:
IAC SB SUBLIMINAL-MESSAGE
DURATION[1] DURATION[0]
FREQUENCY[1] FREQUENCY[0]
MESSAGE_STRING
IAC SE
As required by the Telnet protocol, any occurence of 255 in the
subnegotiation must be doubled to destinguish it from the IAC
character (which has a value of 255).
3. Default.
WONT SUBLIMINAL-MESSAGE
DONT SUBLIMINAL-MESSAGE
i.e., subliminal messages will not be displayed.
4. Motivation for the option
Frequently the use of "Message of the day" banners and newsletters is
insufficient to convince stubborn users to upgrade to the latest
version of telnet. Some users will use the same outdated version for
years. I ran across this problem trying to convince people to use
the REMOTE-FLOW-CONTROL Telnet option. These users need to be gently
"persuaded".
5. Description and implementation notes.
The quality of the client implementation will depend on it's ability
to display and erase text strings in a small amount of time. The
current implementation at CMU takes into acount terminal line speed,
advanced video capabilities, and screen phospher persistance when
calculating how long to wait before erasing a message.
While it is permitted for the client to display the message text
"in-line", best results at obtained by printing the message at the
top or side of console screen where it will just catch the corner of
the user's visual field.
A version is currently under development at CMU to display the
message using morse-code over the keyboard caps-lock LED.
6. Examples
In the following example all numbers are in decimal notation.
1. Server suggests and client agrees to use SUBLIMINAL-MESSAGE.
(Server sends) IAC DO SUBLIMINAL-MESSAGE
(Client sends) IAC WILL SUBLIMINAL-MESSAGE
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Use VMS" IAC SE
[The server is "suggesting" that the user employ a stable
operating system, not an unreasonable request...]
The client should immediately begin displaying the message and
should continue to do so at regular intervals.
2. Server preempts previous subliminal message.
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 5 0 20 "Go home" IAC SE
The client should now no longer display the previous message and
should immediately begin displaying the new one.
3. Server has messed with user enough for one day.
(Server sends) IAC SB SUBLIMINAL-MESSAGE 0 0 0 0 "" IAC SE
The client must cease display of any subliminal messages.
7. Acknowledgements.
We do things just a little sneakier here at CMU.
AI ELI5
On this page
§1The Upgrade Problem
This is an April 1st joke document. RFC 1097 is written as if it were a serious protocol specification, but it is pure humor, not a real standard. The RFC frames the problem humorously: users resist upgrading to newer versions of Telnet, continuing to use outdated software for years despite banners and newsletters. The author encountered this problem at CMU and notes that gentler persuasion had failed. The solution, presented tongue-in-cheek, is to use Telnet to display subliminal messages that the conscious mind does not notice but the brain supposedly absorbs, motivating users to upgrade.
This is a joke. It says: "People won't upgrade to the new Telnet. What if we showed them secret messages so fast they don't notice, but their brains do?" It is silly.
§2The SUBLIMINAL-MESSAGE Option
The RFC defines a SUBLIMINAL-MESSAGE Telnet option with code 257, following standard Telnet negotiation. The sender uses the WILL, WONT, DO, and DONT commands to negotiate whether subliminal messages are enabled. The actual message is sent via subnegotiation: a 16-bit duration (in milliseconds), a 16-bit frequency (in seconds between displays), and a message string.
The RFC includes implementation notes suggesting that the client's ability to erase messages quickly depends on terminal capabilities and phosphor persistence. CMU's implementation takes into account line speed and terminal capabilities. A version under development at the time even proposed displaying messages using Morse code on the keyboard caps-lock LED.
The joke defines pretend commands to turn subliminal messages on or off, and how to send them: how long to show them, how often to show them, and what message to show.
§3Subliminal Persuasion in Action
The RFC includes three examples. In the first, a server sends the message "Use VMS" repeatedly, which the author jokingly notes is "a stable operating system, not an unreasonable request." In the second, the server replaces one message with another ("Go home"). In the third, the server sends an empty message to stop all subliminal messaging.
The RFC concludes with a playful acknowledgment from CMU that "we do things just a little sneakier here at CMU," cementing the humorous intent.
The examples show how a server could flash "Use VMS" at you over and over, or change what message it is showing, or stop showing messages.