Second thoughts on Telnet Go-Ahead
RFC 596

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 596 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            E. Taft
Request for Comments: 596                                      PARC-MAXC
NIC: 15372                                               8 December 1973

                   Second Thoughts on Telnet Go-Ahead


   In this RFC we present objections to the requirement that hosts
   implement the Telnet Go-Ahead (GA) command, as specified in the
   Telnet Protocol Specification (NIC #15372).  The thrust of these
   objections is in three major directions:

      1. The GA mechanism is esthetically unappealing, both to myself
      and to many other people I have talked to.  I shall attempt to
      describe why this is so.

      2. As specified in the Protocol, GA will not, in general, work;
      i.e. it will not serve its intended purpose unless hosts make
      various unwarranted assumptions about how other hosts operate.

      3. GA is impossible for most hosts to implement correctly in all
      cases.  This is certainly true of the PDP-10 operating systems
      with which I am familiar (10/50 and Tenex).

   The purpose of this RFC is to advocate either complete removal of the
   GA mechanism or relegating it to the status of a negotiated option
   whose default state is that it be suppressed.


   "Half-duplex" is a two-way communication discipline in which
   transmission takes place in only one direction at a time and the
   receiving party is constrained not to transmit until the transmitting
   party has explicitly given up control of the communication path
   ("turned the line around").

   This definition is distinct from a common (but incorrect) use of the
   terms "half-duplex" and "full-duplex" to designate local and remote
   character echoing.

   "Reverse break" is a means by which a computer connected to a
   terminal by a half-duplex path may regain control of the path for
   further typeout after previously having relinquished it.

Taft                                                            [Page 1]
RFC 596            Second Thoughts on Telnet Go-Ahead      December 1973

   This is the complement of the "break" or "attention" mechanism,
   implemented by all half-duplex terminals, by means of which the user
   may gain control of the line while it is in use by the computer.


   One assumption that permeates the Telnet Protocol specification (and
   is explicitly stated on Page 7) is that the "normal" mode of
   communication between computers and terminals is half-duplex, line-
   at-a-time.  While historically this is partially true, it is also
   clear, both within the ARPA Network community and elsewhere, that the
   trend is toward highly interactive man-machine communication systems
   which are difficult to implement under half-duplex communication

   The GA mechanism is an attempt to solve a specific problem, that of
   switching control between computer and user in a subset of those
   hosts utilizing IBM 2741 or equivalent terminals.  I say "a subset"
   because in fact the problem arises only in the case of TIPs from
   2741s (with reverse break); from what experience I have had, I think
   the TIP does a very good job of turning the line around at the right
   moments.  (I am told this is also the case at Multics).

   Given the trend toward more interactive communication, and given the
   fact that terminals on the Network requiring a Go-Ahead mechanism are
   a distinct minority of all terminals, I think we should be reluctant
   to burden our protocols with kludges that are so clearly a concession
   to obsolete design.

      I have little doubt that before long somebody (if not IBM) will
      produce a full-duplex 2741-like terminal (indeed, perhaps it has
      already been done).  There is an obvious need for a terminal with
      Selectric quality keyboard and hard-copy better suited to
      interactive applications (i.e. full-duplex).

   As a more practical consideration, it makes little sense to have the
   default state of the GA option be the one that benefits the least
   number of hosts and terminals.

      There is no question that most parties to Telnet communication
      will immediately negotiate to suppress GA.  To do otherwise will
      double the amount of network traffic generated by character-at-a-
      time typein, and will increase it by a non-negligible amount even
      for a line-at-a-time typein.

      It strikes me as worthwhile to minimize the number of such
      "necessary" option negotiations, especially in view of the large
      number of TIPs and mini-hosts on the Network.  Many such hosts

Taft                                                            [Page 2]
RFC 596            Second Thoughts on Telnet Go-Ahead      December 1973

      must, due to resource constraints, implement only a limited subset
      of the available options.  It follows, then, that the default
      state of all options should be the one most hosts will be willing
Show full document text