RFC 855

RFC 855: TELNET OPTION SPECIFICATIONS 💖

Bestie, the title block is giving everything 🎀

• Number: RFC 855
• Authors: J. Postel and J. Reynolds, ISI
• Category: Standard. It specifies a standard for the ARPA Internet community, and hosts on the ARPA Internet are expected to adopt and implement it. 🫶
• Date: May 1983
• Obsoletes: NIC 18640

Okay so the whole point of TELNET options is to let hosts find better solutions for talking to totally different devices than the Network Virtual Terminal (NVT) framework allows. 🦋 Hosts should be able to invent, test, or toss options whenever they want, no cap. 💅 BUT if an option turns out to be genuinely useful, lots of hosts will end up supporting it, so it's lowkey important that options are carefully documented and well publicized. ✨ Also, one option code must never be reused for several different options, because that would be chaos 💀

This document lays out how option codes get assigned and what the documentation has to look like. The person in charge of assigning option codes can waive full documentation for some experimental stuff, but usually docs are required before a code gets assigned. Options get publicized by publishing their docs as RFCs. Inventors can also spread the word other ways, obviously. 📣

Option codes get assigned by:

Jonathan B. Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511

Mailbox = POSTEL@USC-ISIF

Option docs should contain at least these sections:

• Section 1 - Command Name and Option Code
• Section 2 - Command Meanings
• Section 3 - Default Specification
• Section 4 - Motivation
• Section 5 - Description (or Implementation Rules)

For Section 2, you describe what each possible TELNET command means for this option. 🧚 For complex options that need "subnegotiation", there can be way more commands, and we'll get into that below.

For Section 3, you spell out the default assumptions for hosts that don't implement or use the option. 🌸

For Section 4, explain why the option was invented, or why it got its particular form. 🥹 This is extremely helpful for people who aren't dealing with the problem the option solves (or who don't realize they are).

For Section 5, just defining command meanings and writing a motivation isn't always enough to make sure two implementations can actually talk to each other. 😭 So in most cases you should include a fuller description. It can be text, a sample implementation, hints for implementers, etc. 🍓

A Note on "Subnegotiation" 🎀

Some options need more info passed between hosts than one option code can carry. Anything that takes a parameter is one of these. ✨ The strategy has two steps: first both parties agree to "discuss" the parameter(s), and second, the "discussion" happens.

Step one, agreeing to discuss, happens the normal way. One party proposes the option by sending a DO (or WILL) followed by the option code, and the other party accepts by sending back a WILL (or DO) followed by the option code. 💅 Once both sides agree to use the option, subnegotiation kicks off: the SB command, then the option code, then the parameter(s), then the SE command. 🦋 Each party is presumed to be able to parse the parameter(s), since each already said the option is supported during the initial WILL and DO exchange. The receiver can find the end of a parameter string by searching for SE (that's the string IAC SE), even if it can't parse the parameters. 🔥 And either party can refuse to keep subnegotiating at any time by sending a WON'T or DON'T to the other party. 🙈

So for an option "ABC" that needs subnegotiation, the TELNET command formats look like this:

IAC WILL ABC
IAC DO ABC
IAC SB ABC <parameters> IAC SE

• IAC WILL ABC offers to use option ABC (or favorably acknowledges the other party's request). 🌈
• IAC DO ABC requests that the other party use option ABC (or favorably acknowledges the other party's offer). 💜
• IAC SB ABC <parameters> IAC SE is one step of subnegotiation, and either party can send it. ✨

Designers of options that need subnegotiation have to be super careful to avoid endless loops in the subnegotiation process. 💀 For example, say each party accepts any value of a parameter, and both parties suggest parameters with different values. Then you could get an infinite oscillation of "acknowledgments", where each receiver thinks it's only acknowledging the other party's new proposal. Bestie, that is a nightmare. 😭

Last thing: if the parameters in an option's subnegotiation include a byte with the value 255, that byte has to be doubled, following the general TELNET rules. 🫶 Periodt. 👑