rfc1123.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,441 行 · 第 1/5 页

              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



Internet Engineering Task Force                                [Page 20]




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
         CR LF as input from a remote terminal, the effect MUST be the
         same as if the user had pressed the "end-of-line" key on a
         local terminal.  On server hosts that use ASCII, in particular,
         receipt of the Telnet sequence CR LF must cause the same effect
         as a local user pressing the CR key on a local terminal.  Thus,
         CR LF and CR NUL MUST have the same effect on an ASCII server
         host when received as input over a Telnet connection.

         A User Telnet MUST be able to send any of the forms: CR LF, CR
         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
         user-controllable mode to send either CR LF or CR NUL when the
         user presses the "end-of-line" key, and CR LF SHOULD be the
         default.

         The Telnet end-of-line sequence CR LF MUST be used to send
         Telnet data that is not terminal-to-computer (e.g., for Server
         Telnet sending output, or the Telnet protocol incorporated
         another application protocol).

         DISCUSSION:
              To allow interoperability between arbitrary Telnet clients
              and servers, the Telnet protocol defined a standard
              representation for a line terminator.  Since the ASCII
              character set includes no explicit end-of-line character,
              systems have chosen various representations, e.g., CR, LF,
              and the sequence CR LF.  The Telnet protocol chose the CR
              LF sequence as the standard for network transmission.

              Unfortunately, the Telnet protocol specification in RFC-
              854 [TELNET:1] has turned out to be somewhat ambiguous on
              what character(s) should be sent from client to server for
              the "end-of-line" key.  The result has been a massive and
              continuing interoperability headache, made worse by
              various faulty implementations of both User and Server



Internet Engineering Task Force                                [Page 21]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              Telnets.

              Although the Telnet protocol is based on a perfectly
              symmetric model, in a remote login session the role of the
              user at a terminal differs from the role of the server
              host.  For example, RFC-854 defines the meaning of CR, LF,
              and CR LF as output from the server, but does not specify
              what the User Telnet should send when the user presses the
              "end-of-line" key on the terminal; this turns out to be
              the point at issue.

              When a user presses the "end-of-line" key, some User
              Telnet implementations send CR LF, while others send CR
              NUL (based on a different interpretation of the same
              sentence in RFC-854).  These will be equivalent for a
              correctly-implemented ASCII server host, as discussed
              above.  For other servers, a mode in the User Telnet is
              needed.

              The existence of User Telnets that send only CR NUL when
              CR is pressed creates a dilemma for non-ASCII hosts: they
              can either treat CR NUL as equivalent to CR LF in input,
              thus precluding the possibility of entering a "bare" CR,
              or else lose complete interworking.

              Suppose a user on host A uses Telnet to log into a server
              host B, and then execute B's User Telnet program to log
              into server host C.  It is desirable for the Server/User
              Telnet combination on B to be as transparent as possible,
              i.e., to appear as if A were connected directly to C.  In
              particular, correct implementation will make B transparent
              to Telnet end-of-line sequences, except that CR LF may be
              translated to CR NUL or vice versa.

         IMPLEMENTATION:
              To understand Telnet end-of-line issues, one must have at
              least a general model of the relationship of Telnet to the
              local operating system.  The Server Telnet process is
              typically coupled into the terminal driver software of the
              operating system as a pseudo-terminal.  A Telnet end-of-
              line sequence received by the Server Telnet must have the
              same effect as pressing the end-of-line key on a real
              locally-connected terminal.

              Operating systems that support interactive character-at-
              a-time applications (e.g., editors) typically have two
              internal modes for their terminal I/O: a formatted mode,
              in which local conventions for end-of-line and other



Internet Engineering Task Force                                [Page 22]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              formatting rules have been applied to the data stream, and
              a "raw" mode, in which the application has direct access
              to every character as it was entered.  A Server Telnet
              must be implemented in such a way that these modes have
              the same effect for remote as for local terminals.  For
              example, suppose a CR LF or CR NUL is received by the
              Server Telnet on an ASCII host.  In raw mode, a CR
              character is passed to the application; in formatted mode,
              the local system's end-of-line convention is used.

      3.3.2  Data Entry Terminals

         DISCUSSION:
              In addition to the line-oriented and character-oriented
              ASCII terminals for which Telnet was designed, there are
              several families of video display terminals that are
              sometimes known as "data entry terminals" or DETs.  The
              IBM 3270 family is a well-known example.

              Two Internet protocols have been designed to support
              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
              option [TELNET:18, TELNET:19].  The DET option drives a
              data entry terminal over a Telnet connection using (sub-)
              negotiation.  SUPDUP is a completely separate terminal
              protocol, which can be entered from Telnet by negotiation.
              Although both SUPDUP and the DET option have been used
              successfully in particular environments, neither has
              gained general acceptance or wide implementation.

              A different approach to DET interaction has been developed
              for supporting the IBM 3270 family through Telnet,
              although the same approach would be applicable to any DET.
              The idea is to enter a "native DET" mode, in which the
              native DET input/output stream is sent as binary data.
              The Telnet EOR command is used to delimit logical records
              (e.g., "screens") within this binary stream.

         IMPLEMENTATION:
              The rules for entering and leaving native DET mode are as
              follows:

              o    The Server uses the Terminal-Type option [TELNET:10]
                   to learn that the client is a DET.

              o    It is conventional, but not required, that both ends
                   negotiate the EOR option [TELNET:9].

              o    Both ends negotiate the Binary option [TELNET:3] to



Internet Engineering Task Force                                [Page 23]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


                   enter native DET mode.

              o    When either end negotiates out of binary mode, the
                   other end does too, and the mode then reverts to
                   normal NVT.


      3.3.3  Option Requirements

         Every Telnet implementation MUST support the Binary option
         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
         Record [TELNET:9], and Extended Options List [TELNET:8]
         options.

         A User or Server Telnet SHOULD support the Window Size Option
         [TELNET:12] if the local operating system provides the
         corresponding capability.

         DISCUSSION:
              Note that the End-of-Record option only signifies that a
              Telnet can receive a Telnet EOR without crashing;
              therefore, every Telnet ought to be willing to accept
              negotiation of the End-of-Record option.  See also the
              discussion in Section 3.2.3.

      3.3.4  Option Initiation

         When the Telnet protocol is used in a client/server situation,
         the server SHOULD initiate negotiation of the terminal
         interaction mode it expects.

         DISCUSSION:
              The Telnet protocol was defined to be perfectly
              symmetrical, but its application is generally asymmetric.
              Remote login has been known to fail because NEITHER side
              initiated negotiation of the required non-default terminal
              modes.  It is generally the server that determines the
              preferred mode, so the server needs to initiate the
              negotiation; since the negotiation is symmetric, the user
              can also initiate it.

         A client (User Telnet) SHOULD provide a means for users to
         enable and disable the initiation of option negotiation.

         DISCUSSION:
              A user sometimes needs to connect to an application
              service (e.g., FTP or SMTP) that uses Telnet for its



Internet Engineering Task Force                                [Page 24]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              control stream but does not support Telnet options.  User
              Telnet may be used for this purpose if initiation of
              option negotiation is  disabled.

      3.3.5  Telnet Linemode Option

         DISCUSSION:
              An important new Telnet option, LINEMODE [TELNET:12], has
              been proposed.  The LINEMODE option provides a standard
              way for a User Telnet and a Server Telnet to agree that
              the client rather than the server will perform terminal
              character processing.  When the client has prepared a
              complete line of text, it will send it to the server in
              (usually) one TCP packet.  This option will greatly
              decrease the packet cost of Telnet sessions and will also
              give much better user response over congested or long-
              delay networks.

              The LINEMODE option allows dynamic switching b