1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1080.txt b/doc/rfc/rfc1080.txt
new file mode 100644
index 0000000..d42158b
--- /dev/null
+++ b/doc/rfc/rfc1080.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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
+   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.
+
+   Currently, only two command codes are defined for the
+   subnegotiations: flow control off (code 0) and flow control on (code
+   1).  Neither of these codes requires any additional data.  However it
+   is possible that additional commands may be added.  Thus
+   subnegotiations having command codes other than 0 and 1 should be
+   ignored.
+
+      Here is an example of use of this option:
+
+         Host1: IAC DO TOGGLE-FLOW-CONTROL
+
+         Host2: IAC WILL TOGGLE-FLOW-CONTROL
+
+         (Host1 is now free to send commands to change flow control.
+         Note that host2 must now have enabled flow control.)
+
+
+
+
+
+
+Hedrick                                                         [Page 3]
+
+RFC 1080           Telnet Remote Flow Control Option       December 1988
+
+
+         Host1: IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
+
+         Host1: IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
+
+Author's Address:
+
+   Charles Hedrick
+   Rutgers University
+   Center for Computer and Information Services
+   Hill Center, Busch Campus
+   P.O. Box 879
+   Piscataway, NJ 08855-0879
+
+   Phone: (201) 932-3088
+
+   Email: HEDRICK@ARAMIS.RUTGERS.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hedrick                                                         [Page 4]
+
+\ No newline at end of file