Telnet Remote Flow Control Option

Software flow control (XON/XOFF) preempts characters that host software may need as normal input — editors in particular commonly use Ctrl-S and Ctrl-Q — requiring a mechanism for the host to disable flow control at the telnet client.

The initial restart behavior (RESTART-ANY vs. RESTART-XON) after a DO/WILL exchange is left system-dependent to maintain backward compatibility with older RFC 1080 implementations that do not understand the new suboptions.

The option addresses only flow control of data transmitted from the telnet process to the terminal, not from terminal to server, because the latter seldom needs to change repeatedly during a session.

The protocol is intentionally asymmetric: the sender of DO is normally the host and the sender of WILL is normally the user telnet process connected to a terminal, though symmetric use is not prohibited.

In most RESTART-ANY implementations, the character that re-enables output is not consumed by the terminal driver unless it is the XON character itself.

In most software flow control implementations, XOFF and XON characters are consumed by the terminal driver between the telnet client and the terminal and are never forwarded to the server.

Some clients may be unable to support RESTART-ANY or RESTART-XON due to operating system limitations and may silently ignore those suboptions; there is no notification mechanism for this condition.

When the option is disabled by exchange of DONT/WONT, flow control may revert to an implementation-defined default; it is not safe to assume it will remain in the state set by the most recent subnegotiation.

XON/XOFF character identity is not negotiated by this option; that functionality is provided by the Telnet LINEMODE option (RFC 1184).

A client should make every attempt to honor the state requested by the RESTART-ANY and RESTART-XON modes, even though there is no mechanism to notify the server if the client cannot comply.

As soon as DO and WILL have been exchanged, the sender of the WILL must enable flow control, establishing a known initial state.

It is permissible for either side to turn off the option by sending WONT or DONT; once this happens, no more subnegotiations may be sent unless the option is re-enabled by a new DO/WILL exchange.

Subnegotiations MUST NOT be issued until both DO and WILL have been exchanged.

Subnegotiations with command codes other than those defined in this document should be silently ignored, to allow future extensibility.

The sender of the DO should send either a RESTART-ANY or RESTART-XON suboption to put restart characteristics into a known state, since the initial restart behavior is system-dependent.

IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE requests that any character (except another XOFF) may restart output when flow control is enabled. IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC SE restricts restart to the XON character only.

IAC WILL TOGGLE-FLOW-CONTROL signals the sender is willing to enable and disable flow control on command. IAC DO TOGGLE-FLOW-CONTROL signals the sender is willing to issue those commands.

The default state is WONT TOGGLE-FLOW-CONTROL / DONT TOGGLE-FLOW-CONTROL, meaning no flow control information will be exchanged in either direction.

The TOGGLE-FLOW-CONTROL Telnet option is assigned code 33, with four suboption codes: OFF (0), ON (1), RESTART-ANY (2), and RESTART-XON (3).

email

The RFC explicitly states that security issues are not discussed in this memo.

security

Subnegotiations use the form IAC SB TOGGLE-FLOW-CONTROL <code> IAC SE, where <code> is one of OFF (0), ON (1), RESTART-ANY (2), or RESTART-XON (3). No additional data follows the command code.