Comments on The New Telnet Protocol and its Implementation
RFC 559

Document Type RFC - Unknown (August 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 559 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                 Abhay K. Bushan
Request For Comments #559                             MIT Project MAC
NIC # 18482                                           August 15, 1973

       Comments on the new TELNET Protocol and its Implementation

     We at MIT-DN have implemented the new TELNET protocol (both server
and user).  This RFC describes our experience with the implementation
(particularly the use of GO AHEAD) and in bringing the new User and
Server TELNET's in operation (the new TELNET is not compatible with the
old).  We have a few suggestions here which should help other
implementors and lead to a smoother transition to the new protocol.


     Our new server TELNET accepts both the "old" and the "new" TELNET
"control sequences".  Currently we have the ECHO and the "Suppress Go
Ahead" options implemented and do the "right thing" to varying degrees
with the Interrupt Process (IP), Erase Character (EC), Abort Output
(AO), Are You There (AYT), Break, and Synch character sequences.

 A. The ECHO Option

     The TELNET server comes up in the default local echo mode and
accepts both the old and the new TELNET control sequences.  The server
starts the negotiation for remote echo (server echoing) by sending the
sequence "IAC WILL ECHO" but changes the echo mode only when an
affirmative "IAC DO ECHO" is received.  After the cutoff date for old
protocol we will stop "honoring" the old TELNET control sequences.

 B. The Go Ahead and Suppress GA option

     The server comes up in the send GA mode and transmits the required
"IAC GA" sequence whenever the server detects that it needs to send a
GA.  It should be noted that our scheme for sending GA's works most but
not all of the time.

     There is really no reliable way for our server TELNET to find out
when a process is actually waiting for network input.  On our system,
the server TELNET does not "control" user's process, it only acts as a
terminal handler at the TTY level.

Bushan                                                          [Page 1]
RFC 559                    Comments on TELNET                August 1973

     A quick investigation revealed that the above problem (of sending
GA's reliably) is not confined to the ITS operating system alone.  In
fact TENEX (ref. conversation with Ray Tomlinson) and DEC-10 (ref.
conversation with Ed Taft at Harvard) systems will encounter similar

     Our solution to the GA sending problem was to have the server wait
2.5 seconds after sending output to see if there is more output to be
sent.  If the server has been "idle" for more than 2.5 seconds in the
"output-sent" state it sends a GA and goes in an I/O wait state (looking
for input or output).  This scheme works most (but not guaranteed all)
of the time and doesn't cause any noticeable delay.  It is possible for
the server to send an extra GA.  Our experimentation revealed that 1-5
seconds was a good range for this "idling time constant".

     We do implement the "suppress GA" option and will not send GA to
hosts who agree to negotiate out of it.  Our server tries to negotiate
these suppress GA option.

 C. Other Options and TELNET Control Sequences

     Our server will refuse all other options by sending the appropriate
DONTs and WONTs.  In addition to the ECHO and Suppress GA options we
recognize the following TELNET "control sequences".

1. Interrupt Process (IP) - The server substitutes the system wide
interrupt character <control-Z> (ACII SUB) which immediately interrupts
the process, moving control to the immediately superior process.  If the
user is several levels down his process tree he may have to send several
IP's to reach top level.  It should be noted that the IP does not
interrupt the running process in the sense a <control-G> interrupts
muddle but only passes control to the superior.

2. Erase Character (EC) - The server substitutes the system wide
standard erase character <rubout> (ACII DEL).  The deletion however is
done not by the server but by the receiving process.  It is conceivable
that some process (such as a user TELNET) take no action on receiving
EC.  Most processes will echo the deleted character(s).  Several EC's
will delete the several previous characters.  (If the console is
declared to be an IMLAC, the deleted character is removed from the

3. Abort Output (AO) - The server substitutes the character <control-S>
(ACII DC3).  The control-S convention is followed by many but not all of
our programs.  The action taken on receiving AO varies with the program.

Bushan                                                          [Page 2]
RFC 559                    Comments on TELNET                August 1973

A normal occurrence is that output and the current command are aborted
(without necessarily going to completion).  In many programs there is no
way to stop output except by sending an IP and "killing" the inferior
Show full document text