Telnet remote flow control option
RFC 1080

Document Type RFC - Unknown (November 1988; No errata)
Obsoleted by RFC 1372
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1080 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Hedrick
Request for Comments: 1080                            Rutgers University
                                                           November 1988

                   Telnet Remote Flow Control Option

Status of This Memo

   This RFC specifies a standard for the Internet community.  Hosts on
   the Internet that do remote flow control within the Telnet protocol
   are expected to adopt and implement this standard.  Distribution of
   this memo is unlimited.

Motivation

   This memo describes a method of remotely toggling flow control
   between a user telnet process and the attached terminal.  Only flow
   control of data being transmitted from the telnet process to the
   terminal is considered.  Many systems will also allow flow control of
   data from the terminal to the telnet process.  However there is
   seldom need to change this behavior repeatedly during the session.

   There are two common ways of doing flow control: hardware and
   software.  Hardware flow control uses signals on wires dedicated for
   this purpose.  Software flow control uses one or two specific
   characters sent along the same path as normal input data.  Most
   commonly, XOFF (control-S) and XON (control-Q) are used to stop and
   start output, respectively.  The option described herein is useful
   primarily where software flow control is being used.  (Since hardware
   flow control does not preempt any characters, there is normally no
   need to disable it.)

   The primary difficulty with software flow control is that it preempts
   one or two characters.  Host software often requires the user to be
   able to input every possible ASCII character.  (Certain editors are
   notorious for having XOFF and XON as commonly-used commands.)  For
   this reason, operating systems often allow programs to disable flow
   control.  While it is 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 by the
   host computer.  Thus this RFC defines a way to propagate flow control
   status from the host computer to the user telnet process.

Hedrick                                                         [Page 1]
RFC 1080           Telnet Remote Flow Control Option       December 1988

1. Command Name and Code

      TOGGLE-FLOW-CONTROL

      Code = 33

2. Command Meanings

      IAC WILL TOGGLE-FLOW-CONTROL

         Sender is willing to enable and disable flow control upon
         command.

      IAC WON'T TOGGLE-FLOW-CONTROL

         Sender refuses to enable and disable flow control.  Nothing is
         implied about whether sender does or does not use flow control.
         It is simply unwilling to enable and disable it using this
         protocol.

      IAC DO TOGGLE-FLOW-CONTROL

         Sender is willing to send commands to enable and disable flow
         control.

      IAC DON'T TOGGLE-FLOW-CONTROL

         Sender refuses to send command to enable and disable flow
         control.

      IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE

         Sender requests receiver to disable flow control.  The code for
         OFF is 0.

      IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

         Sender requests receiver to enable flow control.  The code for
         ON is 1.

3. Default

      WON'T TOGGLE-FLOW-CONTROL

         Flow control information will not be exchanged.

Hedrick                                                         [Page 2]
RFC 1080           Telnet Remote Flow Control Option       December 1988

      DON'T TOGGLE-FLOW-CONTROL

         Flow control information will not be exchanged.

4. Description of the Option

   Use of the option requires 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 only one exchange of WILL and DO for a session.  Subnegotiations
   must not be issued until DO and WILL have been exchanged.  It is
   permissible for either side to turn off the option by sending a WONT
   or DONT.  Should this happen, no more subnegotiations may be sent,
   unless the option is reenabled 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 to enable and
   disable flow control in the other process.  Normally, the sender of
   the DO will be a host, and the other end will be a user telnet
   process, which is connected to a terminal.  Thus the protocol is
   normally asymmetric.  However it may be used in both directions
   without confusion should need for this arise.

   As soon as the DO and WILL have been exchanged, the sender of the
   WILL must enable flow control.  This allows flow control to begin in
   a known state.  Should the option be disabled by exchange of DONT and
Show full document text