consulted for information about the procedure for establishing new
   options.

THE NETWORK VIRTUAL TERMINAL

   The Network Virtual Terminal (NVT) is a bi-directional character
   device.  The NVT has a printer and a keyboard.  The printer responds
   to incoming data and the keyboard produces outgoing data which is
   sent over the TELNET connection and, if "echoes" are desired, to the
   NVT's printer as well.  "Echoes" will not be expected to traverse the
   network (although options exist to enable a "remote" echoing mode of
   operation, no host is required to implement this option).  The code
   set is seven-bit USASCII in an eight-bit field, except as modified
   herein.  Any code conversion and timing considerations are local
   problems and do not affect the NVT.

   TRANSMISSION OF DATA

      Although a TELNET connection through the network is intrinsically
      full duplex, the NVT is to be viewed as a half-duplex device
      operating in a line-buffered mode.  That is, unless and until





 


RFC 854                                                         May 1983


      options are negotiated to the contrary, the following default
      conditions pertain to the transmission of data over the TELNET
      connection:

         1)  Insofar as the availability of local buffer space permits,
         data should be accumulated in the host where it is generated
         until a complete line of data is ready for transmission, or
         until some locally-defined explicit signal to transmit occurs.
         This signal could be generated either by a process or by a
         human user.

         The motivation for this rule is the high cost, to some hosts,
         of processing network input interrupts, coupled with the
         default NVT specification that "echoes" do not traverse the
         network.  Thus, it is reasonable to buffer some amount of data
         at its source.  Many systems take some processing action at the
         end of each input line (even line printers or card punches
         frequently tend to work this way), so the transmission should
         be triggered at the end of a line.  On the other hand, a user
         or process may sometimes find it necessary or desirable to
         provide data which does not terminate at the end of a line;
         therefore implementers are cautioned to provide methods of
         locally signaling that all buffered data should be transmitted
         immediately.

         2)  When a process has completed sending data to an NVT printer
         and has no queued input from the NVT keyboard for further
         processing (i.e., when a process at one end of a TELNET
         connection cannot proceed without input from the other end),
         the process must transmit the TELNET Go Ahead (GA) command.

         This rule is not intended to require that the TELNET GA command
         be sent from a terminal at the end of each line, since server
         hosts do not normally require a special signal (in addition to
         end-of-line or other locally-defined characters) in order to
         commence processing.  Rather, the TELNET GA is designed to help
         a user's local host operate a physically half duplex terminal
         which has a "lockable" keyboard such as the IBM 2741.  A
         description of this type of terminal may help to explain the
         proper use of the GA command.

         The terminal-computer connection is always under control of
         either the user or the computer.  Neither can unilaterally
         seize control from the other; rather the controlling end must
         relinguish its control explicitly.  At the terminal end, the
         hardware is constructed so as to relinquish control each time
         that a "line" is terminated (i.e., when the "New Line" key is
         typed by the user).  When this occurs, the attached (local)



 


RFC 854                                                         May 1983


         computer processes the input data, decides if output should be
         generated, and if not returns control to the terminal.  If
         output should be generated, control is retained by the computer
         until all output has been transmitted.

         The difficulties of using this type of terminal through the
         network should be obvious.  The "local" computer is no longer
         able to decide whether to retain control after seeing an
         end-of-line signal or not; this decision can only be made by
         the "remote" computer which is processing the data.  Therefore,
         the TELNET GA command provides a mechanism whereby the "remote"