RFC 1372

Telnet Remote Flow Control Option

📅 published October 1992, from ietf

RFC 1372: Telnet Remote Flow Control Option 🦋

Network Working Group 🌸
Request for Comments: 1372
Authors: C. Hedrick (Rutgers University) and D. Borman (Cray Research, Inc.) 👯
Status: IAB standards track protocol ✨
Date: October 1992 📅
Obsoletes: RFC 1080 💅

Status of This Memo 📜

Okay, the official fine print, bestie. This RFC specifies an IAB standards track protocol for the Internet community, and it requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited. 🌈

Introduction ✨

So this doc is an extended version of the Telnet Remote Flow Control Option (RFC 1080) that adds two new suboptions, RESTART-ANY and RESTART-XON. Main character energy 👑

1. Command Names and Codes 💖

Here are the names and their numbers. TOGGLE-FLOW-CONTROL is 33, and it has its own sub-commands:

TOGGLE-FLOW-CONTROL   33
    OFF                    0
    ON                     1
    RESTART-ANY            2
    RESTART-XON            3

2. Command Meanings 🎀

Okay, here's what each message means, one by one:

IAC WILL TOGGLE-FLOW-CONTROL: The sender is willing to enable and disable flow control on command. 🙌
IAC WONT TOGGLE-FLOW-CONTROL: The sender refuses to enable and disable flow control. Nothing is implied about whether the sender does or does not use flow control. It's just unwilling to enable and disable it using this protocol. 🙅
IAC DO TOGGLE-FLOW-CONTROL: The sender is willing to send commands to enable and disable flow control. 🫶
IAC DONT TOGGLE-FLOW-CONTROL: The sender refuses to send commands to enable and disable flow control. 💀
IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE: The sender requests that the receiver disable flow control. 🛑
IAC SB TOGGLE-FLOW-CONTROL ON IAC SE: The sender requests that the receiver enable flow control. ✅
IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE: The sender requests that, when flow control is enabled, the receiver allow any character (except another XOFF) to restart output. 🦋
IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC SE: The sender requests that, when flow control is enabled, the receiver allow only the XON character to restart output. 🔥

3. Default Specification 🧚

The default for this option is:

WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-CONTROL

which means flow control information will not be exchanged in either direction. Quiet, but make it make sense 🙈

4. Motivation 🍓

This memo describes a way to remotely toggle flow control between a user telnet process and the terminal attached to it. Only flow control of data being sent from the telnet process to the terminal is considered here. Lots of systems will also let you flow control data going from the terminal to the telnet process, but you rarely need to change that over and over during a session, so it's not the focus. 💅

There are two common ways to do flow control: hardware and software. Hardware flow control uses signals on wires dedicated to that purpose. Software flow control uses one or two specific characters sent along the same path as normal input. Most commonly, XOFF (control-S) and XON (control-Q) are used to stop and start output, respectively. This option is mainly useful when software flow control is being used. (Since hardware flow control doesn't preempt any characters, there's normally no need to disable it. 🙃) It's also worth knowing that flow control can be generated automatically by the terminal when its buffers are close to overflowing, or manually by the user when they can't read the information as fast as it's being displayed and unread information starts scrolling off the screen. 📜

Here's the big problem with software flow control: it preempts one or two characters. Host software often requires the user to be able to input every possible ASCII character, and certain editors are notorious for using XOFF and XON as commonly used commands. 💀 Because of this, operating systems often let programs disable flow control. While it's disabled, the characters that normally signal flow control may be read as normal input. In a telnet environment, flow control is normally done by the user telnet process, not the host computer. On top of that, many operating systems let the user choose, when flow control is enabled, whether XOFF is the only character allowed to re-enable output, or whether any typed character should re-enable the flow of data. So this RFC defines a way to propagate flow control status from the host computer to the user telnet process. Iconic behavior, honestly 👑

5. Description of the Option 🌸

Using this option takes two phases. In the first phase, the telnet processes agree that one of them will TOGGLE-FLOW-CONTROL. WILL and DO are used only in this first phase. In general there will be just one exchange of WILL and DO for a session. Subnegotiations must not be issued until DO and WILL have been exchanged. Either side may turn the option off by sending a WONT or DONT. If that happens, no more subnegotiations may be sent unless the option is re-enabled by another exchange of DO and WILL. 🔐

Once the hosts have exchanged 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, and to send subnegotiations with recommendations on when to restart output. Normally the sender of the DO is a host, and the other end is a user telnet process connected to a terminal. So the protocol is normally asymmetric, but it can be used in both directions without confusion if that ever becomes necessary. 🔄

As soon as the DO and WILL have been exchanged, the sender of the WILL must enable flow control. This lets flow control begin in a known state. Whether output restarts only when the XON character is received, or when any character is received, starts in a system dependent state. (This keeps things consistent with older implementations of TOGGLE-FLOW-CONTROL that don't understand the RESTART-ANY and RESTART-XON suboptions. 🧸) The sender of the DO should send either a RESTART-ANY or RESTART-XON suboption to put the restart characteristics into a known state. Some clients might not be able to support both RESTART-ANY and RESTART-XON modes due to system limitations, and they would then choose to ignore these commands. There's no way for the server to be notified of this condition, but a client should make every attempt to honor the state requested by the RESTART-ANY and RESTART-XON modes. If the option is disabled by an exchange of DONT and WONT, flow control may revert to an implementation-defined default state. It's not safe to assume that flow control will stay in the state requested by the most recent subnegotiation. ⚠️

In most implementations of software flow control, when it's enabled, the XOFF and XON characters are never propagated to the server. They're typically eaten by the terminal driver between the telnet client and the attached terminal. In most implementations that support RESTART-ANY, the typed character that re-enables output is not eaten by the terminal driver, unless it's the XON character. 🧚

Right now, only four command codes are defined for the subnegotiations: flow control off (code 0), flow control on (code 1), restart output on any character (code 2), and restart output only on XON (code 3). None of these codes requires any additional data, but additional commands may be added in the future. So subnegotiations with command codes other than the ones defined in this document should be silently ignored. 🙈

This option doesn't deal with letting the DO side tell the WILL side which characters should be used for XON and XOFF. That's already handled by the LINEMODE [1] option. 💖

6. Example 🦋

Here's an example of how this option gets used:

       Client                           Server
                                        IAC DO TOGGLE-FLOW-CONTROL
       IAC WILL TOGGLE-FLOW-CONTROL
       [ The server is now free to send commands to change flow control.
         Note that the client must now have enabled flow control, but
         that whether it is restart on XON only or on any character is
         client specific.  ]
                                        IAC SB TOGGLE-FLOW-CONTROL
                                        RESTART-ANY IAC SE

       [ The client should now switch to allowing output to restart when
         the user types any character, if the client is able to support
         that functionality.  ]
                                        IAC SB TOGGLE-FLOW-CONTROL OFF
                                        IAC SE
                                        IAC SB TOGGLE-FLOW-CONTROL ON
                                        IAC SE

References 📚

[1] Internet Engineering Task Force, Telnet Working Group, D. Borman, Editor, "Telnet Linemode Option", RFC 1184, Cray Research, Inc., October 1990. 🧾

Acknowledgments 🫶

The original spec for this option was written by Charles Hedrick and published as RFC 1080. The RESTART-ANY and RESTART-XON suboptions were defined and added to this version of the document by David Borman. Thank you, icons 🌟

Security Considerations 💀

Security issues are not discussed in this memo. Not even a little. Go in with your eyes open 👀

Authors' Addresses 💌

David Borman
- Cray Research, Inc.
- 655F Lone Oak Drive
- Eagan, MN 55121
- Phone: (612) 452-6650
- Email: dab@CRAY.COM
Charles Hedrick
- Director, LCSR Computing Facility
- Rutgers University
- 227 CORE Building
- P.O. Box 879
- Piscataway, NJ 08855-0879
- Phone: (908) 932-3088
- Email: hedrick@cs.rutgers.edu
Mailing List: telnet-ietf@CRAY.COM 📬

📦 where this page comes from

ietf: rfc1372 1992-10
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms