RFC 651

Revised Telnet Status Option 🎀

Okay bestie, this is the RFC that revises the Telnet STATUS option 💅 It was written by D. Crocker (UCLA-NMC) on 25 Oct. 74 and filed under NIC 31154. The doc number is RFC 651 ✨

• Title: Revised Telnet Status Option
• Request for Comments: 651
• Author: D. Crocker (UCLA-NMC)
• Date: 25 Oct. 74
• NIC: 31154 (25 Oct. 74)
• Online file: <[ISI]<DCROCKER>STATUS-OPTION-REVISION.RNO
• The original doesn't list a category, or anything it obsoletes or updates 🙈

1. Command name and code 💖

The option is called STATUS, and its code is 5 🧚

STATUS  5

2. Command meanings 🦋

Okay so this option is described in the NAOL and NAOP option specs, and it applies to a simplex connection 🌸 Here's what each command is giving:

• IAC DO STATUS: the sender of DO wants to be able to send requests for status-of-options info, or they're confirming they're down to send those requests 🙌
• IAC WILL STATUS: the sender of WILL wants to send status info, or they agree to, either spontaneously or when someone asks later ✨
• IAC DON'T STATUS: the sender is done talking about the current status of options 🫶
• IAC WON'T STATUS: also the sender being done talking about the current status of options. Same energy as DON'T 💀
• IAC SB STATUS SEND IAC SE: the sender asks the receiver to share their own view of the current status of Telnet options. The code for SEND is 1 (more on that below 👀)
• IAC SB STATUS IS ... IAC SE: the sender is spilling their view of the current status of Telnet options. The code for IS is 0 (see below too 🔥)

3. Default 🍓

The default is DON'T STATUS/WON'T STATUS, which just means the status of options won't be discussed at all 😌

4. Motivation for the option 💜

This option 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 lead to the nonterminating request loop problem from (NIC #16237), and nobody wants that 😭 The changes in this paper let STATUS fit into the normal shape of Telnet options by pushing the real transfer of status info into the SB command 🧚 Plus, the number of bytes needed to describe the state of the options is way smaller now, which is literally iconic 🌈

5. Description of the option 🎀

Okay so WILL and DO are now only for getting and granting permission to talk about status later 💅 The actual exchange happens inside option subcommands (IAC SB STATUS...) ✨

Once the two hosts have swapped a WILL and a DO, the WILL STATUS sender is free to send status info whenever, either spontaneously or when the DO sender asks 🦋 At worst, that means the info gets sent twice, which is not the end of the world 🙈 Only the DO sender can send requests (IAC SB STATUS SEND IAC SE), and only the WILL sender can send the actual status info (inside an IAC SB STATUS IS ... IAC SE command) 👑

IS has the subcommands WILL, DO and SB 🫶 They're used EXACTLY the way they're used when Telnet options are being negotiated, except that SB gets ended with SE instead of IAC SE 💖 If you need 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 one single IAC SB STATUS IS ... IAC SE describes the condition of ALL options, which is so efficient it's giving main character energy 💅

Here's an example of the option in action 👇

Host1: IAC DO STATUS
Host2: IAC WILL STATUS
   (Host2 is now free to send status information at any time.
   Solicitations from Host1 are NOT necessary. This should not produce
   any dangerous race conditions. At worst, two IS's will be sent.
Host1 (perhaps): IAC SB STATUS SEND IAC SE
Host2 (the following stream is broken into multiple lines only for
readability. No carriage returns are implied.):
   IAC SB STATUS IS
   WILL ECHO
   DO SUPPRESS-GO-AHEAD
   WILL STATUS
   DO STATUS
   WILL RCTE
   SB RCTE <11><1><24> SE
   DO NAOL
   SB NAOL DS <66> SE
   IAC SE
Explanation of Host2's perceptions: It is responsible for echoing back
the data characters it receives over the Telnet connection; it will not
send Go-Ahead signals; it will both issue and request Status information;
it will send instruction for controlling the other side's terminal
printer; it will discuss the line width for data it is sending.

Basically, Host2 is spilling its whole vibe: it echoes what it gets, skips Go-Ahead, and both issues and requests Status info. It also tells the other side how to handle its terminal printer and talks about line width for the data it's sending 🫶