Telnet Protocol specification
RFC 764

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

IEN 148                                                        J. Postel
RFC 764                                                              ISI
                                                               June 1980

                     TELNET PROTOCOL SPECIFICATION

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.  TCP and the connection establishment procedure are
   documentented in the ARPA Internet Protocol Handbook.

   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,
      applicable even in terminal-to-terminal or process-to-process
      communications, the "user" Host is the Host which initiated the
      communication.

Postel                                                          [Page 1]


                                                                        
June 1980                                               RFC 764, IEN 148
Telnet Protocol Specification                                           

   2.  The principle of negotiated options takes cognizance of the fact
   that many sites 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 various "options" will be sanctioned which can 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, the
   line width, the page length, 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 immediately 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.

      c.  Whenever one party sends an option command to a second party,