Telnet Protocol Specification(1)

　　Network Working Group J. Postel

　　Request for Comments: 854 J. Reynolds

　　ISI

　　Obsoletes: NIC 18639 May 1983

　　TELNETPROTOCOL 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 purpose 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 processes to each other. It is　envisioned that the protocol may also be used for terminal-terminal　communication ("linking") and process-process communication　(distributed computation).

　　GENERAL CONSIDERATIONS

　　A TELNET connection is a Transmission Control Protocol (TCP)　connection used to transmit data with interspersed TELNET control　information.

　　The TELNET Protocol is built upon three main ideas: first, the　concept of a "Network Virtual Terminal"; second, the principle of　negotiated options; and third, a symmetric view of terminals and　processes.

　　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 representation of a canonical terminal.

　　This eliminates the need for "server" and "user" hosts to keep　information about the characteristics of each other's terminals and　terminal handling conventions. All hosts, both user and server, 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 sets), and　being overly inclusive (penalizing users with modest terminals).

　　NOTE: The "user" host is the host to which the physical terminal　is normally attached, and the "server" host is the host which is　normally providing some service. As an alternate point of view,　RFC854May 1983　applicable even in terminal-to-terminal or process-to-process　communications, the "user" 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 services over and　above those available within an NVT, and many users will have　sophisticated terminals and would like to have elegant, rather than　minimal, services. Independent of, but structured within the TELNET　Protocol are various "options" that will be sanctioned and may be　used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to　allow a user and server to agree to use a more elaborate (or perhaps　just different) set of conventions for their TELNET connection. Such　options could include changing the character set, the echo mode, etc.

　　The basic strategy for setting up the use 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  mediately takes　effect; if it is rejected the associated aspect of the connection　remains as specified for an NVT. Clearly, a party may always refuse　a request to enable, and must never refuse a request to disable some　option since all parties must be prepared to support the NVT.

　　The syntax of option negotiation has been set up so that if both　parties request an option simultaneously, each will see 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 seeing the incoming　commands not as acknowledgments 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 send 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-response is essential to prevent endless loops in the　negotiation. It is required that a response be sent to requests　for a change of mode -- even if the mode is not changed.

　　c. Whenever one party sends an option command to a second party,　whether as a request or an acknowledgment, and use of the option　will have any effect on the processing of the data being sent from　the first party to the second, then the command must be inserted　in the data stream at the point where it is desired that it take　RFC854May 1983　effect. (It should be noted that some time will elapse 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 user.)