Network Working Group C. Hedrick
Request for Comments: 1372 Rutgers University
Obsoletes: RFC 1080 D. Borman
Cray Research, Inc.
October 1992
Telnet Remote Flow Control Option
Status of This Memo
This RFC specifies an IAB standards track protocol
for the Internet community, and requests discussion
and suggestions for improvements. Please refer to
the current edition of the "IAB Official Protocol
Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Introduction
This document specifies an extended version of the
Telnet Remote Flow Control Option, RFC 1080, with
the addition of the RESTART-ANY and RESTART-XON suboptions.
1. Command Names and Codes
TOGGLE-FLOW-CONTROL 33
OFF 0
ON 1
RESTART-ANY 2
RESTART-XON 3
2. Command Meanings
IAC WILL TOGGLE-FLOW-CONTROL
Sender is willing to enable and disable flow control
upon command.
IAC WONT 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 DONT 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.
IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
Sender requests receiver to enable flow control.
IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE
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
Sender requests that when flow control is enabled,
the receiver allows only the XON character to restart
output.
3. Default Specification
The default specification for this option is
WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-CONTROL
meaning flow control information will not be exchanged in either
direction.
4. 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.) It should also be noted that flow
control can either be generated automatically by the
terminal when its buffers are close to overflowing,
or manually by the user, when he/she cannot read the
information as fast as it is being displayed, and
unread information will start scrolling off the screen.
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. In addition, many operating
systems, when flow control is enabled, the user may
specify whether the XOFF character is the only character
that is allowed to re-enable the output of data, or
whether any typed character should re-enable the flow
of data. Thus this RFC defines a way to propagate
flow control status from the host computer to the
user telnet process.
5. 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 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 to enable and disable flow control
in the other process, and to send subnegotiations
for recommendations on when to restart output. 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. The
decision of whether to restart output only when the
XON character is received, or when any character received,
starts in a system dependent state. (This is to make
it consistent with older implementations of the TOGGLE-FLOW-CONTROL
option that do not 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 to a know state.
Some clients might not be able to support both of
the RESTART-ANY and RESTART-XON modes due to system
limitations, and would then choose to ignore these
commands. There is 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. Should the option be disabled
by exchange of DONT and WONT, flow control may revert
to an implementation-defined default state. It is
not safe to assume that flow control will remain in
the state requested by the most recent subnegotiation.
In most implementations of software flow control,
when enabled, the XOFF and XON characters are never
propagated to the server; they are typically eaten
by the terminal driver between the telnet client and
the attached terminal. In most implementations that
support the RESTART-ANY functionality, the typed character
that re-enables the output is not eaten by the terminal
driver, unless it is the XON character.
Currently, 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,
however it is possible that additional commands may
be added. Thus subnegotiations having command codes
other than those defined in this document should be
silently ignored.
This option does not deal with the issue of allowing
the DO side of the connection to inform the WILL side
which characters should be used for XON and XOFF.
That functionality is already supplied by the LINEMODE
[1] option.
6. Example
Here is an example of the use of this option:
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 specification 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.
Security Considerations
Security issues are not discussed in this memo.
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
Back to the Telnet Protocol
