Second thoughts in defense of the Telnet Go-Ahead
RFC 595

Document Type RFC - Unknown (December 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 595 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      Wayne Hathaway
Request for Comments # 595                                        AMES-67
NIC # 20617                                                   12 Dec 1973
References: NIC # 20812

            Some Thoughts in Defense of the TELNET Go-Ahead

This note is a reply to Edward Taft's "Second Thoughts on TELNET Go-
Ahead" (NIC #20812).  Specifically, I will attempt to show the
following about the three main directions of his objections:

     1. It is the idea of line-at-a-time systems which are esthetically
     unappealing, not the GA mechanism.  This may be a valid point, but
     given the large number of such systems on the net, it would seem a
     rather academic one.

     2. The specified GA mechanism will in fact work very well between
     (reasonably implemented) line-at-a-time systems, and should provide
     significant help elsewhere.

     3. While the GA mechanism may not be correct in all cases, it can
     provide significant advantages fro the line-at-a-time systems and

   My comments will be arranged under the original headings from the
   subject RFC (NIC #20812).


   The definitions of "half-duplex" and "reverse break" are
   satisfactory.  Two points should be made regarding "reverse break",
   however.  First: having reverse break on the terminal is of course not
   sufficient; the operating system must support it.  As "support" is
   equivalent to "require" in this context, it is not too surprising
   that some systems do not in fact do this.  That is, there are systems
   which will not type through an unlocked keyboard until the user
   manually turns the line around, and the operational problems with
   such systems are much less than might be assumed.  Second, at least on
   IBM 2741's and equivalent, the line turnaround takes a significant
   amount of time, during which user-typed characters may be missed or
   garbled.  In fact, a fairly standard mode of operation with systems
   that use reverse break (including TIP's) is to automatically enter
   a "line delete" character and start over every time the reverse break
   is used while typing, which can hardly be called esthetic.  One
   solution to this problem would be for the system to not use reverse
   break once the user has begun typing (as suggested near the end of
   NIC #20812), but most systems (including TIP's) do not do this.

Hathaway                                                        [Page 1]
RFC 595            In Defense of the TELNET Go-Ahead       December 1973

   Some discussion is also warranted at this point about line-at-a-time
   systems (hereafter abbreviated as LAAT systems).  One prime reason for
   LAAT operation is to avoid the overhead of interrupting the CPU (and
   possibly the user process) for every character typed.  Instead,
   characters are buffered (in a controller, a front-end computer, etc)
   until some "end-of-line" signal is received; they are then passed to
   the system in a group.  This means that the system is totally unaware
   that any typing has occurred until the "end-of-line" signal is sent;
   a partially completed line will literally never be recognized.


   From the above, I feel that one can see that it is the operating mode
   of a system rather than the type of features of its terminals which
   determines whether GA is useful or not.  For example, IBM front-ends
   handle Teletypes in LAAT mode, while the TIP attempts to run 2741's
   as full-duplex devices (with something less than "a very good job at
   turning the line around," from my experience).

   At any rate, the half-duplex/full-duplex debate can go on forever --
   the problem here is to try to smooth the way for users on local LAAT
   systems connected to foreign systems of varying characteristics.


   As mentioned, in LAAT systems no terminal input is recognized until
   the specified "end-of-line" character is entered, preceding characters
   having been buffered in a front-end etc.  This can of course be
   carried over into server TELNET: incoming network messages can be
   buffered at a very low level in the NCP awaiting a TELNET end-of-line
   signal.  User processes wanting input would remain blocked until the
   end-of-line is received, rather than being handed each character as
   it is read.  In fact, this is the implementation in all of the LAAT
   systems with which I am familiar.  The reason for doing this is
   obvious: many hosts continue to send single characters even in LAAT
   systems, resulting in a significant increase in overhead.  Equally
   obvious is the fact that in this mode the GA mechanism will function
   quite well, in fact as well as turning the line around to unlock the
   keyboard of a local terminal.

Hathaway                                                        [Page 2]
RFC 595            In Defense of the TELNET Go-Ahead       December 1973
Show full document text