Telnet X.3 PAD option
RFC 1053

Document Type RFC - Historic (April 1988; No errata)
Last updated 2013-10-01
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1053 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text