RFC 859

RFC 859: TELNET STATUS OPTION 💖

okay bestie, this is RFC 859 🎀 J. Postel and J. Reynolds wrote it at ISI in May 1983, and it obsoletes RFC 651 (NIC 31154) 🌸 It's a standard for the ARPA Internet community, so hosts on the ARPA Internet are expected to adopt and implement it ✨

---

1. Command Name and Code ✨

the command is called STATUS and its code is 5 💅

STATUS 5

2. Command Meanings 🦋

this option works separately for each direction of data flow, so each side gets its own say 🫶

2.1. Refusing the Discussion 😭

• IAC DON'T STATUS: the sender refuses to carry on any further discussion of the current status of options. nope, not doing it 💀
• IAC WON'T STATUS: same energy! the sender refuses to carry on any further discussion of the current status of options 🙅‍♀️

2.2. Asking and Telling 🌈

• IAC SB STATUS SEND IAC SE: the sender asks the receiver to send over its own perception of the current status of Telnet options 👀 the code for SEND is 1, see below ✨
• IAC SB STATUS IS ... IAC SE: the sender shares its own perception of the current status of Telnet options 💜 the code for IS is 0, see below ✨

3. Default 🍓

by default, the current status of options is not discussed. DON'T STATUS and WON'T STATUS both mean that nothing gets talked about 🙈

4. Motivation for the Option 🧚

this option is what lets a user or process check the current status of TELNET options (like echoing) the way the person or process on the other end sees them 👑 just renegotiating options could get you stuck in the nonterminating request loop problem from the General Consideration section of the TELNET Specification, which is literally a nightmare 😭 so this option fits neatly into the normal structure of TELNET options by putting the actual status transfer inside the SB command 🔥

5. Description of the Option 💅

okay this part is the main event 🎀 WILL and DO are only used to get and grant permission for future discussion. the real status exchange happens inside the option subcommands (IAC SB STATUS...) ✨

once two hosts have exchanged a WILL and a DO, the sender of the WILL STATUS is free to send status information, either spontaneously or when the sender of the DO asks for it 💖 at worst, that means the info gets sent twice, which is fine tbh 🌸 only the sender of the DO may send requests (IAC SB STATUS SEND IAC SE), and only the sender of the WILL may send the actual status information (inside an IAC SB STATUS IS ... IAC SE command) 🦋

IS has the subcommands WILL, DO and SB 🌈 they're used EXACTLY the same way they're used during the actual negotiation of TELNET options, with one twist: SB gets ended with SE instead of IAC SE ⭐ if you want to send SE as a regular data byte, you double it (SE SE) 🙈 options that aren't explicitly described are assumed to be in their default states 🫶 and a single IAC SB STATUS IS ... IAC SE describes the condition of ALL options at once, which is so efficient 🔥

here's an example of how it goes 🧚

Host1: IAC DO STATUS

Host2: IAC WILL STATUS

Host2 is now free to send status information at any time, and Host1's solicitations are NOT necessary 🙌 this shouldn't cause any dangerous race conditions. at worst, two ISs will be sent 💀

Host1 (perhaps): IAC SB STATUS SEND IAC SE

and then Host2 responds with the following stream. it's broken into multiple lines only for readability, so no carriage returns are implied 🎀

IAC SB STATUS IS

WILL ECHO

DO SUPPRESS-GO-AHEAD

WILL STATUS

DO STATUS

IAC SE

so what does Host2's stream actually mean? 👑 it's responsible for echoing back the data characters it receives over the TELNET connection ✨ it will not send Go-Ahead signals 🙅‍♀️ and it will both issue and request Status information 💜 literally iconic, periodt 💅