with Telnet.

              However, there exist applications that really need an 8-
              bit NVT mode, which is currently not defined, and these
              existing applications do set the high-order bit during
              part or all of the life of a Telnet connection.  Note that
              binary mode is not the same as 8-bit NVT mode, since
              binary mode turns off end-of-line processing.  For this
              reason, the requirements on the high-order bit are stated
              as SHOULD, not MUST.

              RFC-854 defines a minimal set of properties of a "network
              virtual terminal" or NVT; this is not meant to preclude
              additional features in a real terminal.  A Telnet
              connection is fully transparent to all 7-bit ASCII
              characters, including arbitrary ASCII control characters.




 



RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              For example, a terminal might support full-screen commands
              coded as ASCII escape sequences; a Telnet implementation
              would pass these sequences as uninterpreted data.  Thus,
              an NVT should not be conceived as a terminal type of a
              highly-restricted device.

      3.2.6  Telnet Command Structure: RFC-854, p. 13

         Since options may appear at any point in the data stream, a
         Telnet escape character (known as IAC, with the value 255) to
         be sent as data MUST be doubled.

      3.2.7  Telnet Binary Option: RFC-856

         When the Binary option has been successfully negotiated,
         arbitrary 8-bit characters are allowed.  However, the data
         stream MUST still be scanned for IAC characters, any embedded
         Telnet commands MUST be obeyed, and data bytes equal to IAC
         MUST be doubled.  Other character processing (e.g., replacing
         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
         there is no end-of-line convention (see Section 3.3.1) in
         binary mode.

         DISCUSSION:
              The Binary option is normally negotiated in both
              directions, to change the Telnet connection from NVT mode
              to "binary mode".

              The sequence IAC EOR can be used to delimit blocks of data
              within a binary-mode Telnet stream.

      3.2.8  Telnet Terminal-Type Option: RFC-1091

         The Terminal-Type option MUST use the terminal type names
         officially defined in the Assigned Numbers RFC [INTRO:5], when
         they are available for the particular terminal.  However, the
         receiver of a Terminal-Type option MUST accept any name.

         DISCUSSION:
              RFC-1091 [TELNET:10] updates an earlier version of the
              Terminal-Type option defined in RFC-930.  The earlier
              version allowed a server host capable of supporting
              multiple terminal types to learn the type of a particular
              client's terminal, assuming that each physical terminal
              had an intrinsic type.  However, today a "terminal" is
              often really a terminal emulator program running in a PC,
              perhaps capable of emulating a range of terminal types.
              Therefore, RFC-1091 extends the specification to allow a




 



RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              more general terminal-type negotiation between User and
              Server Telnets.

   3.3  SPECIFIC ISSUES

      3.3.1  Telnet End-of-Line Convention

         The Telnet protocol defines the sequence CR LF to mean "end-
         of-line".  For terminal input, this corresponds to a command-
         completion or "end-of-line" key being pressed on a user
         terminal; on an ASCII terminal, this is the CR key, but it may
         also be labelled "Return" or "Enter".

         When a Server Telnet receives the Telnet end-of-line sequence