Comments on The New Telnet Protocol and its Implementation (RFC0559)
Original Publication Date: 1973-Aug-15
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
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.
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.
I. OUR TELNET SERVER IMPLEMENTATION
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.
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 Option...