Network Working Group J. Postel Request for Comments: 854 J. Reynolds ISI Obsoletes: NIC 18639 May 1983 TELNET PROTOCOL SPECIFICATION
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. INTRODUCTION
The purpo of the TELNET Protocol is to provide a fairly general,
bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal
devices and terminal-oriented process to each other. It is
envisioned that the protocol may also be ud for terminal-terminal
communication ("linking") and process-process communication
(distributed computation).
GENERAL CONSIDERATIONS
A TELNET connection is a Transmission Control Protocol (TCP)
connection ud to transmit data with intersperd TELNET control
information.
The TELNET Protocol is built upon three main ideas: first, the
concept of a "Network Virtual Terminal"; cond, the principle of
negotiated options; and third, a symmetric view of terminals and
process.
1. When a TELNET connection is first established, each end is
assumed to originate and terminate at a "Network Virtual Terminal",
or NVT. An NVT is an imaginary device which provides a standard,
network-wide, intermediate reprentation of a canonical terminal.
特困户申请书
This eliminates the need for "rver" and "ur" hosts to keep
information about the characteristics of each other’s terminals and
川芎的作用terminal handling conventions. All hosts, both ur and rver, map their local device characteristics and conventions so as to appear to be dealing with an NVT over the network, and each can assume a
similar mapping by the other party. The NVT is intended to strike a balance between being overly restricted (not providing hosts a rich
enough vocabulary for mapping into their local character ts), and
being overly inclusive (penalizing urs with modest terminals).
NOTE: The "ur" host is the host to which the physical terminal is normally attached, and the "rver" host is the host which is
normally providing some rvice. As an alternate point of view, Postel & Reynolds [Page 1]
RFC 854 May 1983 applicable even in terminal-to-terminal or process-to-process
异常的近义词
communications, the "ur" host is the host which initiated the
communication.
2. The principle of negotiated options takes cognizance of the fact that many hosts will wish to provide additional rvices over and
above tho available within an NVT, and many urs will have
sophisticated terminals and would like to have elegant, rather than
minimal, rvices. Independent of, but structured within the TELNET Protocol are various "options" that will be sanctioned and may be
ud with the "DO, DON’T, WILL, WON’T" structure (discusd below) to allow a ur and rver to agree to u a more elaborate (or perhaps just different) t of conventions for their TELNET connection. Such options could include changing the character t, the echo mode, etc. The basic strategy for tting up the u of options is to have
either party (or both) initiate a request that some option take
effect. The other party may then either accept or reject the
request. If the request is accepted the option immediately takes
effect; if it is rejected the associated aspect of the connection
remains as specified for an NVT. Clearly, a party may always refu a request to enable, and must never refu a request to disable some option since all parties must be prepared to support the NVT.
The syntax of option negotiation has been t up so that if both
parties request an option simultaneously, each will e the other’s
request as the positive acknowledgment of its own.
3. The symmetry of the negotiation syntax can potentially lead to
nonterminating acknowledgment loops -- each party eing the incoming commands not as ackno
wledgments but as new requests which must be
acknowledged. To prevent such loops, the following rules prevail:
a. Parties may only request a change in option status; i.e., a
party may not nd out a "request" merely to announce what mode it is in.
b. If a party receives what appears to be a request to enter some mode it is already in, the request should not be acknowledged.
This non-respon is esntial to prevent endless loops in the
negotiation. It is required that a respon be nt to requests
for a change of mode -- even if the mode is not changed.
c. Whenever one party nds an option command to a cond party,
whether as a request or an acknowledgment, and u of the option
小美女简笔画will have any effect on the processing of the data being nt from the first party to the cond, then the command must be inrted
in the data stream at the point where it is desired that it take Postel & Reynolds [Page 2]
RFC 854 May 1983 effect. (It should be noted that some time will elap between
the transmission of a request and the receipt of an
美好英文acknowledgment, which may be negative. Thus, a host may wish to
buffer data, after requesting an option, until it learns whether
the request is accepted or rejected, in order to hide the
"uncertainty period" from the ur.)
Option requests are likely to flurry back and forth when a TELNET
connection is first established, as each party attempts to get the
best possible rvice from the other party. Beyond that, however,
options can be ud to dynamically modify the characteristics of the connection to suit changing local conditions. For example, the NVT, as will be explained later, us a transmission discipline well
suited to the many "line at a time" applications such as BASIC, but
poorly suited to the many "character at a time" applications such as NLS. A rver might elect to devote the extra processor overhead
required for a "character at a time" discipline when it was suitable for the local process and would negotiate an appropriate option.
However, rather than then being permanently burdened with the extra
processing overhead, it could switch (i.e., negotiate) back to NVT
when the detailed control was no longer necessary.
It is possible for requests initiated by process to stimulate a
nonterminating request loop if the process responds to a rejection by merely re-requesting the option. To prevent such loops from
occurring, rejected requests should not be repeated until something
changes. Operationally, this can mean the process is running a
下定义英语different program, or the ur has given another command, or whatever makes n in the context of the given process and the given option.
A good rule of thumb is that a re-request should only occur as a
result of subquent information from the other end of the connection or when demanded by local human intervention.
Option designers should not feel constrained by the somewhat limited syntax available for option negotiation. The intent of the simple
syntax is to make it easy to have options -- since it is
correspondingly easy to profess ignorance about them. If some
particular option requires a richer negotiation structure than
possible within "DO, DON’T, WILL, WON’T", the proper tack is to u
"DO, DON’T, WILL, WON’T" to establish that both parties understand
the option, and once this is accomplished a more exotic syntax can be ud freely. For example, a party might nd a request to alter
(establish) line length. If it is accepted, then a different syntax can be ud for actually negotiating the line length -- such a
"sub-negotiation" might include fields for minimum allowable, maximum allowable and desired line lengths. The important concept is that Postel & Reynolds [Page 3]
RFC 854 May 1983 such expanded negotiations should never begin until some prior
(standard) negotiation has established that both parties are capable of parsing the expanded syntax.
In summary, WILL XXX is nt, by either party, to indicate that
party’s desire (offer) to begin performing option XXX, DO XXX and
DON’T XXX being its positive and negative acknowledgments; similarly, DO XXX is nt to indicate a desire (request) that the other party
(i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON’T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON’T and
WON’T respons are guaranteed to leave the connection in a state
which both ends can handle. Thus, all hosts may implement their
TELNET process to be totally unaware of options that are not
supported, simply returning a rejection to (i.e., refusing) any
option request that cannot be understood.
As much as possible, the TELNET protocol has been made rver-ur
symmetrical so that it easily and naturally covers the ur-ur
商品的二因素是指(linking) and rver-rver (cooperating process) cas. It is
hoped, but not absolutely required, that options will further this
intent. In any ca, it is explicitly acknowledged that symmetry is an operating principle rather than an ironclad rule.
A companion document, "TELNET Option Specifications," should be
consulted for information about the procedure for establishing new
options.
THE NETWORK VIRTUAL TERMINAL
The Network Virtual Terminal (NVT) is a bi-directional character
device. The NVT has a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data which is
nt over the TELNET connection and, if "echoes" are desired, to the NVT’s printer as well. "Echoes" will not be expected to traver the network (although options exist to enable a "remote" echoing mode of operation, no host is required to implement this option). The code
t is ven-bit USASCII in an eight-bit field, except as modified
herein. Any code conversion and timing considerations are local
problems and do not affect the NVT.
TRANSMISSION OF DATA
Although a TELNET connection through the network is intrinsically full duplex, the NVT is to be viewed as a half-duplex device
operating in a line-buffered mode. That is, unless and until Postel & Reynolds [Page 4]
RFC 854 May 1983 options are negotiated to the contrary, the following default
conditions pertain to the transmission of data over the TELNET
connection:
1) Insofar as the availability of local buffer space permits, data should be accumulated in the host where it is generated
until a complete line of data is ready for transmission, or
until some locally-defined explicit signal to transmit occurs. This signal could be generated either by a process or by a
human ur.
The motivation for this rule is the high cost, to some hosts,
of processing network input interrupts, coupled with the
default NVT specification that "echoes" do not traver the
network. Thus, it is reasonable to buffer some amount of data at its source. Many systems take some processing action at the end of each input line (even line printers or card punches
frequently tend to work this way), so the transmission should
be triggered at the end of a line. On the other hand, a ur
or process may sometimes find it necessary or desirable to
provide data which does not terminate at the end of a line;
therefore implementers are cautioned to provide methods of
locally signaling that all buffered data should be transmitted immediately.
2) When a process has completed nding data to an NVT printer and has no queued input from the NVT keyboard for further
processing (i.e., when a process at one end of a TELNET
connection cannot proceed without input from the other end),
the process must transmit the TELNET Go Ahead (GA) command.
This rule is not intended to require that the TELNET GA command be nt from a terminal at the end of each line, since rver
hosts do not normally require a special signal (in addition to end-of-line or other locally-defined characters) in order to
commence processing. Rather, the TELNET GA is designed to help a ur’s local host operate a physically half duplex terminal
which has a "lockable" keyboard such as the IBM 2741. A
description of this type of terminal may help to explain the
proper u of the GA command.液液
The terminal-computer connection is always under control of
either the ur or the computer. Neither can unilaterally
ize control from the other; rather the controlling end must
relinguish its control explicitly. At the terminal end, the
hardware is constructed so as to relinquish control each time
that a "line" is terminated (i.e., when the "New Line" key is
typed by the ur). When this occurs, the attached (local) Postel & Reynolds [Page 5]
