rfc1053.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                            S. Levy
Request for Comments: 1053                                   T. Jacobson
                                          Minnesota Supercomputer Center
                                                              April 1988


                         Telnet X.3 PAD Option


Status of this Memo

   This RFC proposes a new option to Telnet for the Internet community,
   and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

1.  Command name and code

   X.3-PAD                30

2.  Command meanings

   IAC  DO     X.3-PAD

      The issuing telnet requests that its peer perform X.3-PAD
      functions, or accepts an offer to do so.

   IAC  DON'T  X.3-PAD

      The issuing telnet demands that its peer not perform or cease
      performing X.3-PAD functions.

   IAC  WILL   X.3-PAD

      The issuing telnet offers to perform X.3-PAD functions or confirms
      that it will do so.

   IAC  WON'T  X.3-PAD

      The issuing telnet refuses to perform X.3-PAD functions or
      indicates that it is ceasing to handle them.

   Typically a server (host) telnet will use DO and DON'T, while a
   client (user) telnet will use WILL and WON'T.  For convenience, in
   the rest of this RFC 'host' and 'user' telnets refer to those saying
   'DO X.3-PAD' or 'WILL X.3-PAD' respectively.

   Both telnet peers may use this option without confusion, as all
   messages unambiguously identify whether they come from the host



Levy & Jacobson                                                 [Page 1]

RFC 1053                 Telnet X.3 PAD Option                April 1988


   ("DO") or the user ("WILL") side.

      Once DO and WILL have been exchanged, the host ("DO") telnet may
      send the following messages:

   IAC SB  X.3-PAD  SET           <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  RESPONSE-SET  <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  SEND          IAC SE

      while the user ("WILL") telnet may send the following messages:

   IAC SB  X.3-PAD  IS            <param1> <value1> ...  IAC SE
   IAC SB  X.3-PAD  RESPONSE-IS   <param1> <value1> ...  IAC SE

   The code for SET          is 0
   The code for RESPONSE-SET is 1
   The code for IS           is 2
   The code for RESPONSE-IS  is 3
   The code for SEND         is 4

      Messages listing parameter-value pairs may contain any number of
      such pairs, including zero.  Each parameter and each value
      occupies one octet, except that 255 (IAC) is doubled wherever it
      appears.

3.  Default conditions

   The initial state is DON'T X.3-PAD, WON'T X.3-PAD.  This RFC does not
   specify default values for most X.3 parameters.  If the host telnet
   wishes a particular initial state (as it normally will), it should
   negotiate for it after exchange of DO/WILL messages.

   X.3-PAD parameter values need not be preserved except when DO/WILL
   X.3-PAD is in effect.  Thus if a host enables ("DO") X.3-PAD,
   negotiates about some parameters, then for some reason disables
   ("DONT") and later re-enables X.3-PAD, it must renegotiate any
   parameters it cares about.

   Keeping in mind that the host telnet may not recognize all the
   parameters known to the user telnet, it is suggested that the user
   telnet's initial parameters allow a reasonable level of service even
   if they are never changed (e.g., it would be unwise to begin with all
   data forwarding conditions disabled).  Extensions to X.3 should
   default to states resembling normal X.3 service where possible.







Levy & Jacobson                                                 [Page 2]

RFC 1053                 Telnet X.3 PAD Option                April 1988


4.  Motivation for the option

   Where interactive terminals (or computers simulating them) are
   attached to host computers across a network, it is often desirable to
   provide them the same services as have long been provided for
   terminals directly attached to those hosts.

   Many systems handle this by simply leaving all character processing
   to the host running the applications.  Each character typed by the
   user is sent, often in its own packet, immediately to the host.  This
   gives good control over interaction, but can cause a significant load
   on hosts and networks.  Long-distance packet networks tend to be
   unreasonably slow or expensive or both when used in this mode.

   Suitable character processing on the client (near the user's
   terminal) can greatly improve the situation.  Unfortunately for
   standardization efforts, there are many possible approaches with
   differing purposes.

   Some have already been proposed as Telnet options.  The Remote
   Controlled Transmission and Echo option, [3], provides fine control
   over local buffering and echoing.  The SUPDUP option, [4], offers a
   variety of input and display functions in terminal-independent form.

   This RFC's proposal is intended to support efficient, approximate
   emulation, across a Telnet connection, of a host's normal handling of
   character-oriented terminals.  Ideally, a user and an application
   program would not need to know whether they were linked by an RS-232
   line or a TCP/IP network, except where the medium required a
   distinction (e.g., when establishing a connection).

   Server implementors would wish for enough to emulate, purely locally,
   everything offered by their host's operating system; on the other
   hand, a standard calling on user telnets to provide all terminal
   handling functions of all known operating systems will find few
   implementors.  One might settle on a subset of common operations, but
   which ones?

   The CCITT world has used one approach to these problems: the set of
   PAD services defined by recommendation X.3.  This RFC proposes that
   the Internet community adopt that solution to handle the same
   problems under Telnet.  It is fairly simple, widely known and used,
   extensible, and solves most of the relevant problems.

   Adopting X.3 would have another advantage.  X.25 is the dominant
   worldwide standard interface between commercial packet networks and
   Internet systems, as evidenced by the DDN's adoption of X.25 basic
   and standard services as replacements for BBN 1822 and HDH.  Telnet



Levy & Jacobson                                                 [Page 3]

RFC 1053                 Telnet X.3 PAD Option                April 1988


   and X.3 PAD traffic will have to coexist on X.25 networks; there will
   be a consequential desire for effective interoperation at the virtual
   terminal level.  Extending Telnet along these lines would vastly
   simplify bridging the two.

   Described here is a scheme for implementing X.3 services and
   negotiating their parameters across a Telnet connection.

5.  Description of the option

   Many, though not all, X.3 services are meaningful in the context of
   remote terminal processing; for some, it may be desirable to allow
   local control (by the user) but not remote control (by the server
   host).  Some functions may not be provided, or provided in only
   limited form, by particular implementations.  In general, an
   implementation should follow the Telnet norm of requesting desired
   service but continuing to function somehow in case it is not
   available.

   Negotiations are asymmetrical.  Since the user telnet is charged with
   local character handling while engaged in the session with the remote
   host, the X.3 parameters "belong" to the user side.  The host telnet
   requests parameter changes with SET or RESPONSE-SET messages.  Host
   requests might be on behalf of an application program, for example,
   disabling local echo while a password is being entered.  The user
   telnet should give its "best effort" to accommodate these requests,
   but guarantees nothing except accurate status reporting.

   A user telnet may allow the local user to request parameter changes
   too, though this RFC does not specify a way.

   Where requests conflict, or where a user telnet cannot satisfy a
   request, the user telnet has the last word, since it does the
   relevant character processing.  It may allow control from the host
   only, from the user only, may seek a compromise type of processing
   and so on, at the implementor's discretion.

   Host ("DO") telnets may also ask the user telnet to SEND its current
   parameter values.  The user ("WILL") telnet must reply to each SEND
   message with a RESPONSE-IS message listing the values of all the
   parameters it knows about.  It is strongly recommended that all
   parameters known to the telnet implementor be included in this list,
   even if their values cannot be changed.  The intent is to give the
   host telnet the most complete information possible about the style of
   interaction which the user telnet is providing.

   If possible, user telnets should also inform the server host (with an
   IS message) whenever local conditions (e.g., user requests) change a



Levy & Jacobson                                                 [Page 4]

RFC 1053                 Telnet X.3 PAD Option                April 1988


   parameter's state.  This may not be feasible in some circumstances,
   and such behavior is negotiable -- see the discussion of parameter 0.

   Note that there are no "error" messages defined in section 2.  Almost
   all detectable errors (use of nonexisistent parameters or undefined
   values for known parameters) are indistinguishable from valid uses of
   options known to one peer but not the other.  Hosts will normally
   wish to poll the user telnet's state after making a request anyway,
   so error responses do not seem to be needed.

   The protocol messages listed in section 2 are to be used as follows.

   SET and RESPONSE-SET ask the user telnet to change its values for the
   given X.3 parameters.  The user telnet ignores unrecognized
   parameters; it sends no reply.  The host sends SET to begin a
   negotiation, when some event on the host side causes a change in the
   desired set of parameters.  The host sends RESPONSE-SET to continue
   negotiation, when it is dissatisfied with the user telnet's choice of
   parameters indicated in a RESPONSE-IS message.  Typically, the host
   will test the user telnet's chosen behavior by issuing a SEND message
   following the SET or RESPONSE-SET, though the user telnet should not
   rely on this.

   A SEND message from the host demands that the user telnet send
   RESPONSE-IS.

   IS and RESPONSE-IS inform the host telnet of the current states of
   some or all of the user telnet's parameters.  The user telnet sends
   IS when the user telnet changes a parameter for some local reason,
   e.g., at a request from the (human) user.  An IS message may but need
   not list all parameters, e.g., it might list just those which
   changed.

   It sends RESPONSE-IS in answer to each SEND request from the host.
   Every RESPONSE-IS should list ALL X.3-PAD parameters known to the
   user telnet implementor, even those which cannot be changed.  Any
   host requests (SET or RESPONSE-SET) received before a SEND message
   should be processed before sending the answering RESPONSE-IS, so that
   their effects are reflected in the parameter values indicated there.

   To permit synchronization (which SEND is this an answer to?), the
   user telnet should count SEND messages, and send exactly one
   RESPONSE-IS per SEND.

   One might think that this protocol could be implemented with only
   SET, SEND and IS messages.  The seemingly redundant RESPONSE-SET and
   RESPONSE-IS codes are needed to let both the user and host telnets
   distinguish new peer requests from attempts to renegotiate previous



Levy & Jacobson                                                 [Page 5]

RFC 1053                 Telnet X.3 PAD Option                April 1988


   actions, while preventing potential infinite negotiation loops.

   SET and IS messages are sent when the host or user telnet wishes to
   inform its peer of a change in the X.3 processing mode desired by
   some higher level entity.  This might happen at initialization, or on
   user or application-program request.  The important thing is that
   these messages are NOT sent merely in response to another X.3-PAD
   message from the peer.