RFC 1080

Telnet Remote Flow Control Option 🎀

Okay bestie, here's the whole vibe check on this one 💖

• Who wrote it: Charles (C.) Hedrick at Rutgers University 🎓
• What it is: an RFC from the Network Working Group, Request for Comments 1080 📜
• When: November 1988 🍂
• Category: the Status of This Memo section says it specifies a standard for the Internet community, so it's standards-track energy 👑
• Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🙈

---

Status of This Memo 📜

Okay so this RFC is literally a standard for the whole Internet community 👑 Any hosts on the Internet that do remote flow control inside the Telnet protocol are expected to adopt and implement it. And distribution is unlimited, so it can go anywhere 🌈

Motivation 💅

This is about remotely toggling flow control between a user telnet process and the attached terminal 🦋 It only covers flow control for data going from the telnet process to the terminal. Plenty of systems also let you flow-control data going from the terminal to the telnet process, but nobody really needs to flip that back and forth during a session.

Okay, two common ways to do flow control: hardware and software 🔌 Hardware flow control uses signals on wires that are dedicated to it. Software flow control uses one or two special characters sent down the same path as your normal input. Usually that's XOFF (control-S) to stop output and XON (control-Q) to start it again 🛑➡️✅ This option is mainly useful where software flow control is being used. (Hardware flow control doesn't preempt any characters, so there's normally no reason to turn it off.)

Here's the tea 🫖 The main problem with software flow control is that it steals characters. Host software often needs you to be able to type every possible ASCII character. (Some editors are notorious for using XOFF and XON as everyday commands 💀) So operating systems often let programs turn flow control off. While it's off, those characters that would normally mean flow control can just come through as regular input. In a telnet setup, flow control is usually handled by the user's telnet process, not the host computer. So this RFC defines a way to pass the host's flow control status along to the user telnet process 🧚

1. Command Name and Code ✨

The command is called TOGGLE-FLOW-CONTROL, and its code is 33.

TOGGLE-FLOW-CONTROL

Code = 33

2. Command Meanings 🦋

Here's what each message means, bestie 🫶

IAC WILL TOGGLE-FLOW-CONTROL

The sender is willing to enable and disable flow control when told to.

IAC WON'T TOGGLE-FLOW-CONTROL

The sender refuses to enable and disable flow control. This doesn't say anything about whether the sender uses flow control or not. It's just unwilling to switch it on or off using this protocol 🙅‍♀️

IAC DO TOGGLE-FLOW-CONTROL

The sender is willing to send commands that enable and disable flow control.

IAC DON'T TOGGLE-FLOW-CONTROL

The sender refuses to send commands that enable and disable flow control.

IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE

The sender asks the receiver to disable flow control. The code for OFF is 0 🔴

IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

The sender asks the receiver to enable flow control. The code for ON is 1 🟢

3. Default 🌸

If nobody's negotiated anything, the defaults are:

WON'T TOGGLE-FLOW-CONTROL

Flow control information won't be exchanged.

DON'T TOGGLE-FLOW-CONTROL

Flow control information won't be exchanged. Same energy as above, no drama 💅

4. Description of the Option 🧚

Using this option happens in two phases 🫶 In the first phase, the telnet processes agree that one of them will TOGGLE-FLOW-CONTROL. WILL and DO only show up in this first phase, and usually there's just one WILL and DO exchange per session. Subnegotiations MUST NOT be issued until DO and WILL have been exchanged. Either side is allowed (permissible, lol) to turn the option off by sending a WONT or DONT. If that happens, no more subnegotiations may be sent, unless the option gets turned back on by another exchange of DO and WILL 🔁

Once the hosts have swapped a WILL and a DO, the sender of the DO TOGGLE-FLOW-CONTROL is free to send subnegotiations that enable and disable flow control in the other process. Normally the DO sender is a host, and the other end is a user telnet process hooked up to a terminal. So the protocol is usually asymmetric ⚖️ It can be used in both directions without confusion if that ever comes up. Iconic flexibility 🦋

As soon as the DO and WILL have been exchanged, the sender of the WILL MUST enable flow control. That way flow control starts in a known state ✨ Should this happen, if the option gets turned off with DONT and WONT, flow control MAY revert to an implementation-defined default state. It's not safe to assume flow control will stay in whatever state the most recent subnegotiation asked for 🙈

Right now only two command codes are defined for subnegotiations: flow control off (code 0) and flow control on (code 1). Neither of them needs any extra data. But it's possible more commands MAY be added later, so subnegotiations with command codes other than 0 and 1 SHOULD be ignored 👀

Here's an example of the whole thing in action 🎬

Host1: IAC DO TOGGLE-FLOW-CONTROL

Host2: IAC WILL TOGGLE-FLOW-CONTROL

(Host1 is now free to send commands to change flow control. Note that host2 MUST now have enabled flow control.)

Host1: IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE

Host1: IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

Author's Address 💌

Charles Hedrick
Rutgers University
Center for Computer and Information Services
Hill Center, Busch Campus
P.O. Box 879
Piscataway, NJ 08855-0879

Phone: (201) 932-3088

Email: HEDRICK@ARAMIS.RUTGERS.EDU

That's the whole RFC, bestie! 🌈💖 Go be a main character in your telnet sessions 👑🫶