RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              stream.  An important application is data entry terminal
              support (see Section 3.3.2).  There was concern that since
              EOR had not been defined in RFC-854, a host that was not
              prepared to correctly ignore unknown Telnet commands might
              crash if it received an EOR.  To protect such hosts, the
              End-of-Record option [TELNET:9] was introduced; however, a
              properly implemented Telnet program will not require this
              protection.

      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10

         When it receives "urgent" TCP data, a User or Server Telnet
         MUST discard all data except Telnet commands until the DM (and
         end of urgent) is reached.

         When it sends Telnet IP (Interrupt Process), a User Telnet
         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
         pointer points to the DM octet.

         When it receives a Telnet IP command, a Server Telnet MAY send
         a Telnet "Synch" sequence back to the user, to flush the output
         stream.  The choice ought to be consistent with the way the
         server operating system behaves when a local user interrupts a
         process.

         When it receives a Telnet AO command, a Server Telnet MUST send
         a Telnet "Synch" sequence back to the user, to flush the output
         stream.

         A User Telnet SHOULD have the capability of flushing output
         when it sends a Telnet IP; see also Section 3.4.5.

         DISCUSSION:
              There are three possible ways for a User Telnet to flush
              the stream of server output data:

              (1)  Send AO after IP.

                   This will cause the server host to send a "flush-
                   buffered-output" signal to its operating system.
                   However, the AO may not take effect locally, i.e.,
                   stop terminal output at the User Telnet end, until
                   the Server Telnet has received and processed the AO
                   and has sent back a "Synch".

              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
                   all output locally until a WILL/WONT TIMING-MARK is




 



RFC1123                  REMOTE LOGIN -- TELNET             October 1989


                   received from the Server Telnet.

                   Since the DO TIMING-MARK will be processed after the
                   IP at the server, the reply to it should be in the
                   right place in the output data stream.  However, the
                   TIMING-MARK will not send a "flush buffered output"
                   signal to the server operating system.  Whether or
                   not this is needed is dependent upon the server
                   system.

              (3)  Do both.

              The best method is not entirely clear, since it must
              accommodate a number of existing server hosts that do not
              follow the Telnet standards in various ways.  The safest
              approach is probably to provide a user-controllable option
              to select (1), (2), or (3).

      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11

         In NVT mode, a Telnet SHOULD NOT send characters with the
         high-order bit 1, and MUST NOT send it as a parity bit.
         Implementations that pass the high-order bit to applications
         SHOULD negotiate binary mode (see Section 3.2.6).


         DISCUSSION:
              Implementors should be aware that a strict reading of
              RFC-854 allows a client or server expecting NVT ASCII to
              ignore characters with the high-order bit set.  In
              general, binary mode is expected to be used for
              transmission of an extended (beyond 7-bit) character set