rfc1123.txt

bind 9.3结合mysql数据库

Internet Engineering Task Force                                [Page 15]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


3.  REMOTE LOGIN -- TELNET PROTOCOL

   3.1  INTRODUCTION

      Telnet is the standard Internet application protocol for remote
      login.  It provides the encoding rules to link a user's
      keyboard/display on a client ("user") system with a command
      interpreter on a remote server system.  A subset of the Telnet
      protocol is also incorporated within other application protocols,
      e.g., FTP and SMTP.

      Telnet uses a single TCP connection, and its normal data stream
      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
      escape sequences to embed control functions.  Telnet also allows
      the negotiation of many optional modes and functions.

      The primary Telnet specification is to be found in RFC-854
      [TELNET:1], while the options are defined in many other RFCs; see
      Section 7 for references.

   3.2  PROTOCOL WALK-THROUGH

      3.2.1  Option Negotiation: RFC-854, pp. 2-3

         Every Telnet implementation MUST include option negotiation and
         subnegotiation machinery [TELNET:2].

         A host MUST carefully follow the rules of RFC-854 to avoid
         option-negotiation loops.  A host MUST refuse (i.e, reply
         WONT/DONT to a DO/WILL) an unsupported option.  Option
         negotiation SHOULD continue to function (even if all requests
         are refused) throughout the lifetime of a Telnet connection.

         If all option negotiations fail, a Telnet implementation MUST
         default to, and support, an NVT.

         DISCUSSION:
              Even though more sophisticated "terminals" and supporting
              option negotiations are becoming the norm, all
              implementations must be prepared to support an NVT for any
              user-server communication.

      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

         On a host that never sends the Telnet command Go Ahead (GA),
         the Telnet Server MUST attempt to negotiate the Suppress Go
         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
         Server Telnet MUST always accept negotiation of the Suppress Go



Internet Engineering Task Force                                [Page 16]




RFC1123                  REMOTE LOGIN -- TELNET             October 1989


         Ahead option.

         When it is driving a full-duplex terminal for which GA has no
         meaning, a User Telnet implementation MAY ignore GA commands.

         DISCUSSION:
              Half-duplex ("locked-keyboard") line-at-a-time terminals
              for which the Go-Ahead mechanism was designed have largely
              disappeared from the scene.  It turned out to be difficult
              to implement sending the Go-Ahead signal in many operating
              systems, even some systems that support native half-duplex
              terminals.  The difficulty is typically that the Telnet
              server code does not have access to information about
              whether the user process is blocked awaiting input from
              the Telnet connection, i.e., it cannot reliably determine
              when to send a GA command.  Therefore, most Telnet Server
              hosts do not send GA commands.

              The effect of the rules in this section is to allow either
              end of a Telnet connection to veto the use of GA commands.

              There is a class of half-duplex terminals that is still
              commercially important: "data entry terminals," which
              interact in a full-screen manner.  However, supporting
              data entry terminals using the Telnet protocol does not
              require the Go Ahead signal; see Section 3.3.2.

      3.2.3  Control Functions: RFC-854, pp. 7-8

         The list of Telnet commands has been extended to include EOR
         (End-of-Record), with code 239 [TELNET:9].

         Both User and Server Telnets MAY support the control functions
         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
         SB, and SE.

         A host MUST be able to receive and ignore any Telnet control
         functions that it does not support.

         DISCUSSION:
              Note that a Server Telnet is required to support the
              Telnet IP (Interrupt Process) function, even if the server
              host has an equivalent in-stream function (e.g., Control-C
              in many systems).  The Telnet IP function may be stronger
              than an in-stream interrupt command, because of the out-
              of-band effect of TCP urgent data.

              The EOR control function may be used to delimit the



Internet Engineering Task Force                                [Page 17]




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



Internet Engineering Task Force                                [Page 18]




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
              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.



Internet Engineering Task Force                                [Page 19]




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