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
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
=10= |