Telnet X.3 PAD option
RFC - Historic
(April 1988; No errata)
||RFC Editor Note
RFC 1053 (Historic)
||Send notices to
Network Working Group S. Levy
Request for Comments: 1053 T. Jacobson
Minnesota Supercomputer Center
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
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
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
Some have already been proposed as Telnet options. The Remote
Controlled Transmission and Echo option, , provides fine control
over local buffering and echoing. The SUPDUP option, , 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