(server) computer can signal the "local" (user) computer that
         it is time to pass control to the user of the terminal.  It
         should be transmitted at those times, and only at those times,
         when the user should be given control of the terminal.  Note
         that premature transmission of the GA command may result in the
         blocking of output, since the user is likely to assume that the
         transmitting system has paused, and therefore he will fail to
         turn the line around manually.

      The foregoing, of course, does not apply to the user-to-server
      direction of communication.  In this direction, GAs may be sent at
      any time, but need not ever be sent.  Also, if the TELNET
      connection is being used for process-to-process communication, GAs
      need not be sent in either direction.  Finally, for
      terminal-to-terminal communication, GAs may be required in
      neither, one, or both directions.  If a host plans to support
      terminal-to-terminal communication it is suggested that the host
      provide the user with a means of manually signaling that it is
      time for a GA to be sent over the TELNET connection; this,
      however, is not a requirement on the implementer of a TELNET
      process.

      Note that the symmetry of the TELNET model requires that there is
      an NVT at each end of the TELNET connection, at least
      conceptually.

   STANDARD REPRESENTATION OF CONTROL FUNCTIONS

      As stated in the Introduction to this document, the primary goal
      of the TELNET protocol is the provision of a standard interfacing
      of terminal devices and terminal-oriented processes through the
      network.  Early experiences with this type of interconnection have
      shown that certain functions are implemented by most servers, but
      that the methods of invoking these functions differ widely.  For a
      human user who interacts with several server systems, these
      differences are highly frustrating.  TELNET, therefore, defines a
      standard representation for five of these functions, as described



 


RFC 854                                                         May 1983


      below.  These standard representations have standard, but not
      required, meanings (with the exception that the Interrupt Process
      (IP) function may be required by other protocols which use
      TELNET); that is, a system which does not provide the function to
      local users need not provide it to network users and may treat the
      standard representation for the function as a No-operation.  On
      the other hand, a system which does provide the function to a
      local user is obliged to provide the same function to a network
      user who transmits the standard representation for the function.

      Interrupt Process (IP)

         Many systems provide a function which suspends, interrupts,
         aborts, or terminates the operation of a user process.  This
         function is frequently used when a user believes his process is
         in an unending loop, or when an unwanted process has been
         inadvertently activated.  IP is the standard representation for
         invoking this function.  It should be noted by implementers
         that IP may be required by other protocols which use TELNET,
         and therefore should be implemented if these other protocols
         are to be supported.

      Abort Output (AO)

         Many systems provide a function which allows a process, which
         is generating output, to run to completion (or to reach the
         same stopping point it would reach if running to completion)
         but without sending the output to the user's terminal.
         Further, this function typically clears any output already
         produced but not yet actually printed (or displayed) on the
         user's terminal.  AO is the standard representation for
         invoking this function.  For example, some subsystem might
         normally accept a user's command, send a long text string to
         the user's terminal in response, and finally signal readiness
         to accept the next command by sending a "prompt" character
         (preceded by ) to the user's terminal.  If the AO were
         received during the transmission of the text string, a
         reasonable implementation would be to suppress the remainder of
         the text string, but transmit the prompt character and the
         preceding .  (This is possibly in distinction to the
         action which might be taken if an IP were received; the IP
         might cause suppression of the text string and an exit from the
         subsystem.)

         It should be noted, by server systems which provide this
         function, that there may be buffers external to the system (in