Summary

  • RFC 1097 said that its SUBLIMINAL-MESSAGE option was a standard, yet the current RFC Editor record classifies the document as Unknown in the Independent Stream, and the IETF Datatracker says it has no formal standing in the IETF standards process.
  • The satire still followed Telnet's refusal-aware shape. Its default was WON'T/DON'T, and a client had to agree through option negotiation before accepting the duration, frequency and message string. That agreement described endpoint state, not informed human consent.
  • The option required the client only to attempt an implementation-dependent display. A received subnegotiation did not prove pixels, perception, persuasion, an upgrade or any later action.

A status paragraph could imitate authority, not create it

RFC 1097 opens in the formal register of a protocol specification. It is dated 1 April 1989, names B. Miller of CMU-NetDev and announces a “TELNET SUBLIMINAL-MESSAGE Option.” Its own status paragraph says the RFC specifies a standard for the Internet community. Section 1 assigns the symbolic option the number 257.

That sentence is part of the historical artifact. It is not the final authority on the artifact.

The current RFC Editor information record labels RFC 1097 Unknown and places it in the Independent Stream. The current IETF Datatracker record is more explicit: the RFC was published as an Independent Submission, is not endorsed by the IETF and has no formal standing in the IETF standards process. The memo's body and the publication record answer different questions. One preserves what the author wrote; the other records how the institution classifies it.

This is not a technicality added to spoil a joke. It is the first mechanism in the story. A document can contain commands, defaults and examples. It can even contain a sentence declaring its own status. None of those fields gives the document the institutional right to classify itself.

The archive kept the joke without turning it into a standard

RFC 8700, the RFC Series' fiftieth-anniversary history, describes April 1 RFCs as a special humorous part of the Independent Stream. It says they have no formal review and approval process of the ordinary kind, while still being selected and reviewed for their special purpose. RFC 1097's date, deadpan form and escalating implementation notes belong to that tradition.

The distinction matters because archives preserve more than operative rules. The RFC Series holds standards, experiments, information, history and humor. Publication proves that the text entered that durable record. It does not make every published sentence an Internet Standard.

RFC 1097 works because it borrows the exact furniture of a serious Telnet option: command meanings, a default, motivation, implementation notes and examples. The parody depends on the reader recognizing the genre. Its archival value comes from the imitation, not from pretending the imitation acquired the authority it copied.

Even the subliminal message had to ask first

The joke also preserves a real Telnet boundary. RFC 854 defines Telnet as a bidirectional, eight-bit byte-oriented facility with a default Network Virtual Terminal and negotiated options. Either peer may propose an option. The other may accept or reject it; an unsupported option can be refused while the connection remains in the common default state.

RFC 855 gives parameterized options a two-stage grammar. First, DO/WILL establishes that the parties can discuss the option. Only then does subnegotiation carry parameters. DON'T or WON'T can stop the arrangement.

RFC 1097 uses that vocabulary with a straight face. WILL requests permission to display subliminal messages or confirms willingness to do so. WON'T refuses. DO requests that the receiver display them or grants the receiver permission. DON'T demands that the receiver not display them. The specified default is WON'T/DON'T: no message is displayed.

The remote sender therefore does not begin with an unconditional right to write on the other screen. The client must first enter the option state. That protection is narrow, but real. Even a fictional coercion channel is framed as a capability that can be refused.

Number 257 sat beyond the ordinary table

The number is another carefully placed seam. Telnet is byte-oriented, and the current IANA Telnet Options registry lists the ordinary option space through 255. Code 255 is Extended-Options-List. There is no current named row for SUBLIMINAL-MESSAGE or option 257.

That does not make 257 an unexplained arithmetic error. RFC 861 had already reserved 255 for EXOPL, a mechanism intended to add another 256 options. It places extended option negotiation inside EXOPL subnegotiation. RFC 1097 names 257, but its examples write the symbolic form IAC DO SUBLIMINAL-MESSAGE and never spell out the EXOPL wire framing.

The defensible conclusion is limited. RFC 1097 situated its joke just beyond the ordinary option list, in territory for which an extension mechanism existed. The cited sources do not prove an IANA assignment for 257, a packet encoding used by an implementation or a deployed exchange. A symbolic option name in a memo and a present registry row are different evidence.

The client agreed; the person did not appear in the handshake

After option agreement, RFC 1097 lets the sender supply two 16-bit values and a string. The first value is display duration in milliseconds; the second is the interval in seconds. The client is told to accept the subnegotiation and attempt to display the message immediately and repeatedly. Position and rendering remain implementation-dependent. A byte with value 255 must be doubled, preserving Telnet's escape rule.

The examples heighten the satire. One message says “Use VMS.” Another replaces it with “Go home.” A final subnegotiation sends zero duration, zero interval and an empty string to stop the display. The motivation complains that banners and newsletters failed to persuade users to upgrade Telnet and refers to the REMOTE-FLOW-CONTROL option. The real RFC 1080 had recently described that option, code 33, with its own prior DO/WILL requirement.

But RFC 1097's agreement is between Telnet endpoints. The document says the client agreed. It never establishes that a person knowingly chose the content, duration, frequency or purpose. A client may have been configured by a developer, administrator or default. Protocol consent is evidence that software entered a state; it is not automatically evidence of human consent.

That distinction cuts both ways. The sender controls the string and timing after negotiation. The receiver controls implementation-dependent placement and rendering. The human controls neither surface merely by being present at the terminal. Compressing all three into “the user agreed” assigns a decision to the wrong actor.

“Attempt to display” stops well before persuasion

The memo's strongest operational verb is “attempt.” That is an honest boundary, even inside the absurd premise.

A subnegotiation can prove that bytes arrived. A client log may prove that the option was enabled and a render routine was invoked. Separate observation would be needed to show that terminal state allowed a visible pulse. More evidence would be needed to show that the person was looking, noticed the pulse, interpreted the string, remembered it, changed a belief, upgraded software or went home.

RFC 1097 also says a CMU implementation accounted for terminal speed, video capabilities and phosphor persistence, and that a Caps Lock LED version using Morse code was under development. Those are claims made by a satirical memo. Without independent records, they are not proof that either implementation shipped, ran or influenced anyone.

The evidence ladder is therefore longer than the joke's punch line: archived text; authoritative publication status; negotiated endpoint capability; received parameters; local display attempt; physical presentation; human perception; persuasion; action. No earlier rung can stand in for a later one.

Sources