rfc854.html

this gives details of the network programming

         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)


Postel & Reynolds                                               [Page 5]
<HR>


<A href="rfc854.html">RFC 854</A>                                                         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"
         (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


Postel &amp; Reynolds                                               [Page 6]
<HR>


<A href="rfc854.html">RFC 854</A>                                                         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 &lt;CR&gt;&lt;LF&gt;) 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 &lt;CR&gt;&lt;LF&gt;.  (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




Postel &amp; Reynolds                                               [Page 7]
<HR>


<A href="rfc854.html">RFC 854</A>                                                         May 1983


         the network and the user's local host) which should be cleared;
         the appropriate way to do this is to transmit the "Synch"
         signal (described below) to the user system.

      Are You There (AYT)

         Many systems provide a function which provides the user with
         some visible (e.g., printable) evidence that the system is
         still up and running.  This function may be invoked by the user
         when the system is unexpectedly "silent" for a long time,
         because of the unanticipated (by the user) length of a
         computation, an unusually heavy system load, etc.  AYT is the
         standard representation for invoking this function.

      Erase Character (EC)

         Many systems provide a function which deletes the last
         preceding undeleted character or "print position"* from the
         stream of data being supplied by the user.  This function is
         typically used to edit keyboard input when typing mistakes are
         made.  EC is the standard representation for invoking this
         function.

            *NOTE:  A "print position" may contain several characters
            which are the result of overstrikes, or of sequences such as
            &lt;char1&gt; BS &lt;char2&gt;...

      Erase Line (EL)

         Many systems provide a function which deletes all the data in
         the current "line" of input.  This function is typically used
         to edit keyboard input.  EL is the standard representation for
         invoking this function.

   THE TELNET "SYNCH" SIGNAL

      Most time-sharing systems provide mechanisms which allow a
      terminal user to regain control of a "runaway" process; the IP and
      AO functions described above are examples of these mechanisms.
      Such systems, when used locally, have access to all of the signals
      supplied by the user, whether these are normal characters or
      special "out of band" signals such as those supplied by the
      teletype "BREAK" key or the IBM 2741 "ATTN" key.  This is not
      necessarily true when terminals are connected to the system
      through the network; the network's flow control mechanisms may
      cause such a signal to be buffered elsewhere, for example in the
      user's host.



Postel &amp; Reynolds                                               [Page 8]
<HR>


<A href="rfc854.html">RFC 854</A>                                                         May 1983


      To counter this problem, the TELNET "Synch" mechanism is
      introduced.  A Synch signal consists of a TCP Urgent notification,
      coupled with the TELNET command DATA MARK.  The Urgent
      notification, which is not subject to the flow control pertaining
      to the TELNET connection, is used to invoke special handling of
      the data stream by the process which receives it.  In this mode,
      the data stream is immediately scanned for "interesting" signals
      as defined below, discarding intervening data.  The TELNET command
      DATA MARK (DM) is the synchronizing mark in the data stream which
      indicates that any special signal has already occurred and the
      recipient can return to normal processing of the data stream.

         The Synch is sent via the TCP send operation with the Urgent
         flag set and the DM as the last (or only) data octet.

      When several Synchs are sent in rapid succession, the Urgent
      notifications may be merged.  It is not possible to count Urgents
      since the number received will be less than or equal the number
      sent.  When in normal mode, a DM is a no operation; when in urgent
      mode, it signals the end of the urgent processing.

         If TCP indicates the end of Urgent data before the DM is found,
         TELNET should continue the special handling of the data stream
         until the DM is found.

         If TCP indicates more Urgent data after the DM is found, it can
         only be because of a subsequent Synch.  TELNET should continue
         the special handling of the data stream until another DM is
         found.

      "Interesting" signals are defined to be:  the TELNET standard
      representations of IP, AO, and AYT (but not EC or EL); the local
      analogs of these standard representations (if any); all other
      TELNET commands; other site-defined signals which can be acted on
      without delaying the scan of the data stream.

      Since one effect of the SYNCH mechanism is the discarding of
      essentially all characters (except TELNET commands) between the
      sender of the Synch and its recipient, this mechanism is specified
      as the standard way to clear the data path when that is desired.
      For example, if a user at a terminal causes an AO to be
      transmitted, the server which receives the AO (if it provides that
      function at all) should return a Synch to the user.

      Finally, just as the TCP Urgent notification is needed at the
      TELNET level as an out-of-band signal, so other protocols which
      make use of TELNET may require a TELNET command which can be
      viewed as an out-of-band signal at a different level.


Postel &amp; Reynolds                                               [Page 9]
<HR>


<A href="rfc854.html">RFC 854</A>                                                         May 1983


      By convention the sequence [IP, Synch] is to be used as such a
      signal.  For example, suppose that some other protocol, which uses
      TELNET, defines the character string STOP analogously to the
      TELNET command AO.  Imagine that a user of this protocol wishes a
      server to process the STOP string, but the connection is blocked
      because the server is processing other commands.  The user should
      instruct his system to:

         1. Send the TELNET IP character;

         2. Send the TELNET SYNC sequence, that is:

            Send the Data Mark (DM) as the only character
            in a TCP urgent mode send operation.

         3. Send the character string STOP; and

         4. Send the other protocol's analog of the TELNET DM, if any.

      The user (or process acting on his behalf) must transmit the
      TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
      gets through to the server's TELNET interpreter.

         The Urgent should wake up the TELNET process; the IP should
         wake up the next higher level process.

   THE NVT PRINTER AND KEYBOARD

      The NVT printer has an unspecified carriage width and page length
      and can produce representations of all 95 USASCII graphics (codes
      32 through 126).  Of the 33 USASCII control codes (0 through 31
      and 127), and the 128 uncovered codes (128 through 255), the
      following have specified meaning to the NVT printer:

         NAME                  CODE         MEANING

         NULL (NUL)              0      No Operation
         Line Feed (LF)         10      Moves the printer to the
                                        next print line, keeping the
                                        same horizontal position.
         Carriage Return (CR)   13      Moves the printer to the left
                                        margin of the current line.