As per Relevance of the word terminal, we have this rfc below:
Network Working Group C.
Request for Comments: 1372 Rutgers
Obsoletes: RFC 1080 D.
Cray Research, Inc
October 1992
Telnet Remote Flow Control
Status of This
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document specifies an extended version of the Telnet Remote
Control Option, RFC 1080, with the addition of the RESTART-ANY
RESTART-XON suboptions
1. Command Names and
TOGGLE-FLOW-CONTROL 33
OFF 0
ON 1
RESTART-ANY 2
RESTART-XON 3
2. Command
IAC WILL TOGGLE-FLOW-
Sender is willing to enable and disable flow control upon command
IAC WONT TOGGLE-FLOW-
Sender refuses to enable and disable flow control. Nothing
implied about whether sender does or does not use flow control
It is simply unwilling to enable and disable it using
protocol
IAC DO TOGGLE-FLOW-
Sender is willing to send commands to enable and disable
control
Hedrick & Borman [Page 1]
RFC 1372 Telnet Remote Flow Control Option October 1992
IAC DONT TOGGLE-FLOW-
Sender refuses to send command to enable and disable flow control
IAC SB TOGGLE-FLOW-CONTROL OFF IAC
Sender requests receiver to disable flow control
IAC SB TOGGLE-FLOW-CONTROL ON IAC
Sender requests receiver to enable flow control
IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC
Sender requests that when flow control is enabled, the
allow any character (except another XOFF) to restart output
IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC
Sender requests that when flow control is enabled, the
allows only the XON character to restart output
3. Default
The default specification for this option
WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-
meaning flow control information will not be exchanged in
direction
4.
This memo describes a method of remotely toggling flow
between a user telnet process and the attached terminal. Only
control of data being transmitted from the telnet process to
terminal is considered. Many systems will also allow flow control
data from the terminal to the telnet process, however there is
need to change this behavior repeatedly during the session
There are two common ways of doing flow control: hardware
software. Hardware flow control uses signals on wires dedicated
this purpose. Software flow control uses one or two
characters sent along the same path as normal input data.
commonly, XOFF (control-S) and XON (control-Q) are used to stop
start output, respectively. The option described herein is
primarily where software flow control is being used. (Since
flow control does not preempt any characters, there is normally
Hedrick & Borman [Page 2]
RFC 1372 Telnet Remote Flow Control Option October 1992
need to disable it.) It should also be noted that flow control
either be generated automatically by the terminal when its
are close to overflowing, or manually by the user, when he/she
read the information as fast as it is being displayed, and
information will start scrolling off the screen
The primary difficulty with software flow control is that it
one or two characters. Host software often requires the user to
able to input every possible ASCII character. (Certain editors
notorious for having XOFF and XON as commonly-used commands.)
this reason, operating systems often allow programs to disable
control. While it is disabled, the characters that normally
flow control may be read as normal input. In a telnet environment
flow control is normally done by the user telnet process, not by
host computer. In addition, many operating systems, when
control is enabled, the user may specify whether the XOFF
is the only character that is allowed to re-enable the output
data, or whether any typed character should re-enable the flow
data. Thus this RFC defines a way to propagate flow control
from the host computer to the user telnet process
5. Description of the
Use of the option requires two phases. In the first phase,
telnet processes agree that one of them will TOGGLE-FLOW-CONTROL
WILL and DO are used only in this first phase. In general there
be only one exchange of WILL and DO for a session.
must not be issued until DO and WILL have been exchanged. It
permissible for either side to turn off the option by sending a
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
TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable
disable flow control in the other process, and to
subnegotiations for recommendations on when to restart output
Normally, the sender of the DO will be a host, and the other end
be a user telnet process, which is connected to a terminal. Thus
protocol is normally asymmetric, however it may be used in
directions without confusion should need for this arise
As soon as the DO and WILL have been exchanged, the sender of
WILL must enable flow control. This allows flow control to begin
a known state. The decision of whether to restart output only
the XON character is received, or when any character received,
in a system dependent state. (This is to make it consistent
older implementations of the TOGGLE-FLOW-CONTROL option that do
understand the RESTART-ANY and RESTART-XON suboptions.) The
Hedrick & Borman [Page 3]
RFC 1372 Telnet Remote Flow Control Option October 1992
of the DO should send either a RESTART-ANY or RESTART-XON
to put the restart characteristics to a know state. Some
might not be able to support both of the RESTART-ANY and RESTART-
modes due to system limitations, and would then choose to
these commands. There is no way for the server to be notified
this condition, but a client should make every attempt to honor
state requested by the RESTART-ANY and RESTART-XON modes. Should
option be disabled by exchange of DONT and WONT, flow control
revert to an implementation-defined default state. It is not safe
assume that flow control will remain in the state requested by
most recent subnegotiation
In most implementations of software flow control, when enabled,
XOFF and XON characters are never propagated to the server; they
typically eaten by the terminal driver between the telnet client
the attached terminal. In most implementations that support
RESTART-ANY functionality, the typed character that re-enables
output is not eaten by the terminal driver, unless it is the
character
Currently, only four command codes are defined for
subnegotiations: flow control off (code 0), flow control on (code 1),
restart output on any character (code 2) and restart output only
XON (code 3). None of these codes requires any additional data
however it is possible that additional commands may be added.
subnegotiations having command codes other than those defined in
document should be silently ignored
This option does not deal with the issue of allowing the DO side
the connection to inform the WILL side which characters should
used for XON and XOFF. That functionality is already supplied by
LINEMODE [1] option
Hedrick & Borman [Page 4]
RFC 1372 Telnet Remote Flow Control Option October 1992
6.
Here is an example of the use of this option
Client
IAC DO TOGGLE-FLOW-
IAC WILL TOGGLE-FLOW-
[ The server is now free to send commands to change flow control
Note that the client must now have enabled flow control,
that whether it is restart on XON only or on any character
client specific. ]
IAC SB TOGGLE-FLOW-
RESTART-ANY IAC
[ The client should now switch to allowing output to restart
the user types any character, if the client is able to
that functionality. ]
IAC SB TOGGLE-FLOW-CONTROL
IAC
IAC SB TOGGLE-FLOW-CONTROL
IAC
[1] Internet Engineering Task Force, Telnet Working Group
D. Borman, Editor, "Telnet Linemode Option", RFC 1184,
Cray Research, Inc., October 1990.
The original specification for this option was written by
Hedrick, and published as RFC 1080. The RESTART-ANY and RESTART-
suboptions were defined and added to this version of the document
David Borman
Security
Security issues are not discussed in this memo
Hedrick & Borman [Page 5]
RFC 1372 Telnet Remote Flow Control Option October 1992
Authors'
David
Cray Research, Inc
655F Lone Oak
Eagan, MN 55121
Phone: (612) 452-6650
Email: dab@CRAY.
Charles
Director, LCSR Computing
Rutgers
227 CORE
P.O. Box 879
Piscataway, NJ 08855-0879
Phone: (908) 932-3088
Email: hedrick@cs.rutgers.
Mailing List: telnet-ietf@CRAY.
Hedrick & Borman [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
