    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,
              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 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 site may wish to buffer data, after requesting an

    [Page 2]                                                          Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

              option, until it learns whether the request is accepted or
              rejected, in order to hide the "uncertainty period" from the
              user.)

       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 service from the other party.  Beyond that, however,
       options can be used to dynamically modify the characteristics of the
       connection to suit changing local conditions.  For example, the NVT,
       as will be explained later, uses 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 server 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 more "taut" control was no longer necessary.

       It is possible for requests initiated by processes 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 user has given another command, or whatever
       makes sense 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 subsequent 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 use
       "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
       used freely.  For example, a party might send a request to alter
       (establish) line length.  If it is accepted, then a different syntax
       can be used for actually negotiating the line length--such a
       "sub-negotiation" perhaps including fields for minimum allowable,
       maximum allowable and desired line lengths.  The important concept is
       that such expanded negotiations should never begin until some prior
       (standard) negotiation has established that both parties are capable
       of parsing the expanded syntax.

    Postel                                                          [Page 3]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

       In summary, WILL XXX is sent, 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 sent 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 responses are guaranteed to leave the connection in a state
       which both ends can handle.  Thus, all Hosts may implement their
       TELNET processes 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 server-user
       symmetrical so that it easily and naturally covers the user-user
       (linking) and server-server (cooperating processes) cases.  It is
       hoped, but not absolutely required, that options will further this
       intent.  In any case, 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.  That document, as well as descriptions of all currently
       defined options, is contained in the TELNET section of the ARPA
       Internet Protocol Handbook.

    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
       sent over the TELNET connection and, if "echoes" are desired, to the
       NVT's printer as well.  "Echoes" will not be expected to traverse the
       network (although options exist to enable a "remote" echoing mode of
       operation, no Host is required to implement this option).  The code
       set is seven-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

    [Page 4]                                                          Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

          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 user.

             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 traverse 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 user
             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 sending 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 sent from a terminal at the end of each line, since server
             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 user'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 use of the GA command.

             The terminal-computer connection is always under control of
             either the user or the computer.  Neither can unilaterally
             seize 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

    Postel                                                          [Page 5]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

             that a "line" is terminated (i.e., when the "New Line" key is
             typed by the user).  When this occurs, the attached (local)
             computer processes the input data, decides if output should be
             generated, and if not returns control to the terminal.  If
             output should be generated, control is retained by the computer
             until all output has been transmitted.

             The difficulties of using this type of terminal through the
             network should be obvious.  The "local" computer is no longer
             able to decide whether to retain control after seeing an
             end-of-line signal or not; this decision can only be made by
             the "remote" computer which is processing the data.  Therefore,
             the TELNET GA command provides a mechanism whereby the "remote"
             (server) computer can signal the "local" (user) computer that
             it is time to pass control to the user of the terminal.  It
             should be transmitted at those times, and only at those times,
             when the user should be given control of the terminal.  Note
             that premature transmission of the GA command may result in the
             blocking of output, since the user is likely to assume that the
             transmitting system has paused, and therefore he will fail to
             turn the line around manually.

          The foregoing, of course, does not apply to the user-to-server
          direction of communication.  In this direction, GAs may be sent at
          any time, but need not ever be sent.  Also, if the TELNET
          connection is being used for process-to-process communication, GAs
          need not be sent in either direction.  Finally, for
          terminal-to-terminal communication, GAs may be required in
          neither, one, or both directions.  If a Host plans to support
          terminal-to-terminal communication it is suggested that the Host
          provide the user with a means of manually signaling that it is
          time for a GA to be sent over the TELNET connection; this,
          however, is not a requirement on the implementer of a TELNET
          process.

       STANDARD REPRESENTATION OF CONTROL FUNCTIONS

          As stated in the Introduction to this document, the primary goal
          of the TELNET protocol is the provision of a standard interfacing
          of terminal devices and terminal-oriented processes through the
          network.  Early experiences with this type of interconnection have
          shown that certain functions are implemented by most servers, but
          that the methods of invoking these functions differ widely.  For a
          human user who interacts with several server systems, these
          differences are highly frustrating.  TELNET, therefore, defines a
          standard representation for five of these functions, as described

    [Page 6]                                                          Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

          below.  These standard representations have standard, but not
          required, meanings (with the exception that the IP function may be
          required by other protocols which use TELNET); that is, a system
          which does not provide the function to local users need not
          provide it to network users and may treat the standard
          representation for the function as a No-operation.  On the other
          hand, a system which does provide the function to local is obliged
          to provide the same function as a network user who transmits the
          standard representation for the function.

          Interrupt Process (IP)

             Many systems provide a function which suspends, interrupts,
             aborts, or terminates the operation of a user process.  This
             function is frequently used when a user believes his process is
             in an unending loop, or when an unwanted process has been
             inadvertently activated.  IP is the standard representation for
             invoking this function.  It should be noted by implementers
             that IP may be required by other protocols which use TELNET,
             and therefore should be implemented if these other protocols
             are to be supported.

          Abort Output (AO)

             Many systems provide a function which allows a process, which
             is generating output, to run to completion (or to reach the
             same stopping point it would reach if running to completion)
             but without sending the output to the user's terminal.
             Further, this function typically clears any output already
             produced but not yet actually printed (or displayed) on the
             user's terminal.  AO is the standard representation for
             invoking this function.  For example, some subsystem might
             normally accept a user's command, send a long text string to
             the user's terminal in response, and finally signal readiness
             to accept the next command by sending a "prompt" character
             (preceded by <CR><LF>) to the user's terminal.  If the AO were
             received during the transmission of the text string, a
             reasonable implementation would be to suppress the remainder of
             the text string, but transmit the prompt character and the
             preceding <CR><LF>.  (This is possibly in distinction to the
             action which might be taken if an IP were received; the IP
             might cause suppression of the text string and an exit from the
             subsystem.)

             It should be noted, by systems which provide this function,
             that there may be buffers external to the system (in the

    Postel                                                          [Page 7]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

             network and the user's "local" Host) which should be cleared;
             the appropriate way to do this is to transmit the "Synch"
             signal described below.

          Are You There (AYT)

             Many systems provide a function which provides the user with
             some visible (e.g., printable) evidence that the system is
             still up and running.  This function may be invoked by the user
             when the system is unexpectedly "silent" for a long time,
             because of the unanticipated (by the user) length of a
             computation, an unusually heavy system load, etc.  AYT is the
             standard representation for invoking this function.

          Erase Character (EC)

             Many systems provide a function which deletes the last
             preceding undeleted character or "print position"* from the
             stream of data being supplied by the user.  This function is
             typically used to edit keyboard input when typing mistakes are
             made.  EC is the standard representation for invoking this
             function.

                *NOTE:  A "print position" may contain several characters
                which are the result of overstrikes, or of sequences such as
                <char1> BS <char2>...

          Erase Line (EL)

             Many systems provide a function which deletes all the data in
             the current "line" of input.  This function is typically used
             to edit keyboard input.  EL is the standard representation for
             invoking this function.

       THE TELNET "SYNCH" SIGNAL

          Most time-sharing systems provide mechanisms which allow a
          terminal user to regain control of a "runaway" process; the IP and
          AO functions described above are examples of these mechanisms.
          Such systems, when used locally, have access to all of the signals
          supplied by the user, whether these are normal characters or
          special "out of band" signals such as those supplied by the
          teletype "BREAK" key or the IBM 2741 "ATTN" key.  This is not
          necessarily true when terminals are connected to the system

    [Page 8]                                                          Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

          through the network; the network's flow control mechanisms may
          cause such a signal to be buffered elsewhere, for example in the
          user's Host.

          To counter this problem, the TELNET "Synch" mechanism is
          introduced.  A Synch signal consists of a TCP Urgent notification,
          coupled with the TELNET command DATA MARK.  The Urgent
          notification, which is not subject to the flow control pertaining
          to the TELNET connection, is used to invoke special handling of
          the data stream by the process which receives it.  In this mode,
          the data stream is immediately scanned for "interesting" signals
          as defined below, discarding intervening data.  The TELNET command
          DATA MARK (DM) is the synchronizing mark in the data stream which
          indicates that any special signal has already occurred and the
          recipient can return to normal processing of the data stream.

             The Synch is sent via the TCP send operation with the Urgent
             flag set and the DM as the last (or only) data octet.

          When several Synchs are sent in rapid succession, the Urgent
          notifications may be merged.  It is not possible to count Urgents
          since the number received will be less than or equal the number
          sent.  When in normal mode a DM is a no operation, when in urgent
          mode it signals the end of the urgent processing (this should
          correspond with the end of Urgent pointer indicated by TCP).

             If TCP indicates the end of Urgent data before the DM is found,
             TELNET should continue the special handling of the data stream
             until the DM is found.

          "Interesting" signals are defined to be:  the TELNET standard
          representations of IP, AO, and AYT (but not EC or EL); the local
          analogs of these standard representations (if any); all other
          TELNET commands; other site-defined signals which can be acted on
          without delaying the scan of the data stream.

          Since one effect of the SYNCH mechanism is the discarding of
          essentially all characters (except TELNET commands) between the
          sender of the Synch and its recipient, this mechanism is specified
          as the standard way to clear the data path when that is desired.
          For example, if a user at a terminal causes an AO to be
          transmitted, the server which receives the AO (if it provides that
          function at all) should return a Synch to the user.

          Finally, just as the TCP Urgent notification is needed at the

    Postel                                                          [Page 9]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

          TELNET level as an out-of-band signal, so other protocols which
          make use of TELNET may require a TELNET command which can be
          viewed as an out-of-band signal at a different level.

          By convention the sequence [IP, Synch] is to be used as such a
          signal.  For example, suppose that some other protocol, which uses
          TELNET, defines the character string STOP analogously to the
          TELNET command AO.  Imagine that a user of this protocol wishes a
          server to process the STOP string, but the connection is blocked
          because the server is processing other commands.  The user should
          instruct his system to:

             1. Send the TELNET IP character;

             2. Send the TELNET SYNC sequence, that is:

                Send the Data Mark (DM) as the only character
                in a TCP urgent mode send operation.

             3. Send the character string STOP; and

             4. Send the other protocol's analog of the TELNET DM, if any.

          The user (or process acting on his behalf) must transmit the
          TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
          gets through to the server's TELNET interpreter.

             The Urgent should wake up the TELNET process, the IP should
             wake up the next higher level process.

       THE NVT PRINTER AND KEYBOARD

          The NVT printer has an unspecified carriage width and page length
          and can produce representations of all 95 USASCII graphics (codes
          32 through 126).  Of the 33 USASCII control codes (0 through 31
          and 127), and the 128 uncovered codes (128 through 255), the
          following have specified meaning to the NVT printer:

             NAME                  CODE         MEANING

             NULL (NUL)              0   A no operation
             Line Feed (LF)         10   Moves the printer to the
                                         next print line, keeping the
                                         same horizontal position
             Carriage Return (CR)   13   Moves the printer to the left
                                         margin of the current line.

    [Page 10]                                                         Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

             In addition, the following codes shall have defined, but not
             required, effects on the NVT printer.  Neither end of a TELNET
             connection may assume that the other party will take, or will
             have taken, any particular action upon receipt or transmission
             of these:

             BELL (BEL)              7   Produces an audible or
                                         visible signal (which does
                                         NOT move the print head)
             Back Space (BS)         8   Moves the print head one
                                         character position towards
                                         the left margin.
             Horizontal Tab (HT)     9   Moves the printer to the
                                         next horizontal tab stop.
                                         It remains unspecified how
                                         either party determines or
                                         establishes where such tab
                                         stops are located.
             Vertical Tab (VT)       11  Moves the printer to the
                                         next horizontal tab stop.It
                                         remains unspecified how
                                         either party determines or
                                         establishes where such tab
                                         stops are located.
             Form Feed (FF)          12  Moves the printer to the top
                                         of the next page, keeping
                                         the same horizontal position

          All remaining codes do not cause the NVT printer to take any
          action.

          The sequence "CR LF", as defined, will cause the NVT to be
          positioned at the left margin of the next print line (as would,
          for example, the sequence "LF CR").  However, many systems and
          terminals do not treat CR and LF independently, and will have to
          go to some effort to simulate their effect.  (For example, some
          terminals do not have a CR independent of the LF, but on such
          terminals it may be possible to simulate a CR by backspacing.)
          Therefore, the sequence "CR LF" must be treated as a single "new
          line" character and used whenever their combined action is
          intended; the sequence "CR NUL" must be used where a carriage
          return alone is actually desired; and the CR character must be
          avoided in other contexts.  This rule gives assurance to systems
          which must decide whether to perform a "new line" function or a
          multiple-backspace that the TELNET stream contains a character
          following a CR that will allow a rational decision.

    Postel                                                         [Page 11]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

             Note that "CR LF" or "CR NUL" is required in both directions
             (in the default ASCII mode), to preserve the symmetry of the
             NVT model.  Even though it may be known in some situations
             (e.g., with remote echo and suppress go ahead options in
             effect) that characters are not being sent to an actual
             printer, none the less, for the sake of consistency, the
             protocol requires that a NUL be inserted following a CR not
             followed by a LF in the data stream.  The converse of this is
             that a NUL received in the data stream after a CR (in the
             absence of options negotiations which explicitly specify
             otherwise) should be stripped out prior to applying the NVT to
             local character set mapping.

          The NVT keyboard has keys, or key combinations, or key sequences,
          for generating all 128 USASCII codes.  Note that although many
          have no effect on the NVT printer, the NVT keyboard is capable of
          generating them.

          In addition to these codes, the NVT keyboard shall be capable of
          generating the following additional codes which, except as noted,
          have defined, but not reguired, meanings.  The actual code
          assignments for these "characters" are in the TELNET Command
          section, because they are viewed as being, in some sense, generic
          and should be available even when the data stream is interpreted
          as being some other character set.

          Synch

             This key allows the user to clear his data path to the other
             party.  The activation of this key causes a DM (see command
             section) to be sent in the data stream and a TCP Urgent
             notification is associated with it.  The pair DM-Urgent is to
             have required meaning as defined previously.

          Break (BRK)

             This code is provided because it is a signal outside the
             USASCII set which is currently given local meaning within many
             systems.  It is intended to indicate that the Break Key or the
             Attention Key was hit.  Note, however, that this is intended to
             provide a 129th code for systems which require it, not as a
             synonym for the IP standard representation.

    [Page 12]                                                         Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

          Interrupt Process (IP)

             Suspend, interrupt, abort or terminate the process to which the
             NVT is connected.  Also, part of the out-of-band signal for
             other protocols which use TELNET.

          Abort Output (AO)

             Allow the current process to (appear to) run to completion, but
             do not send its output to the user.  Also, send a Synch to the
             user.

          Are You There (AYT)

             Send back to the NVT some visible (i.e., printable) evidence
             that the AYT was received.

          Erase Character (EC)

             The recipient should delete the last preceding undeleted
             character or "print position" from the data stream.

          Erase Line (EL)

             The recipient should delete characters from the data stream
             back to, but not including, the last "CR LF" sequence sent over
             the TELNET connection.

          The spirit of these "extra" keys, and also the printer format
          effectors, is that they should represent a natural extension of
          the mapping that already must be done from "NVT" into "local".
          Just as the NVT data byte 104 should be mapped into whatever the
          local code for "uppercase D" is, so the EC character should be
          mapped into whatever the local "Erase Character" function is.
          Further, just as the mapping for 174 is somewhat arbitrary in an
          environment that has no "vertical bar" character, the EL character
          may have a somewhat arbitrary mapping (or none at all) if there is
          no local "Erase Line" facility.  Similarly for format effectors:
          if the terminal actually does have a "Vertical tab", then the
          mapping for VT is obvious, and only when the terminal does not
          have a vertical tab should the effect of VT be unpredictable.

    Postel                                                         [Page 13]

    June 1980                                               RFC 764, IEN 148
    Telnet Protocol Specification

    TELNET COMMAND STRUCTURE

       All TELNET commands consist of at least a two byte sequence:  the
       "Interpret as Command" (IAC) escape character followed by the code
       for the command.  The commands dealing with option negotiation are
       three byte sequences, the third byte being the code for the option
       referenced.  This format was chosen so that as more comprehensive use
       of the "data space" is made -- by negotiations from the basic NVT, of
       course -- collisions of data bytes with reserved command values will
       be minimized, all such collisions requiring the inconvenience, and
       inefficiency, of "escaping" the data bytes into the stream.  With the
       current set-up, only the IAC need be doubled to be sent as data, and
       the other 255 codes may be passed transparently.

       The following are the defined TELNET commands.  Note that these codes
       and code sequences have the indicated meaning only when immediately
       preceded by an IAC.

          NAME               CODE              MEANING

          SE                  240 End of subnegotiation parameters
          NOP                 241 No operation
          Data Mark           242 The data stream portion of a Synch
                                  This should always be accompanied
                                  by a TCP Urgent notification.
          Break               243 NVT character BRK
          Interrupt Process   244 The function IP
          Abort output        245 The function AO
          Are You There       246 The function AYT
          Erase character     247 The function EC
          Erase Line          248 The function EL
          Go ahead            249 The GA signal
          SB                  250 Indicates that what follows is
                                  subnegotiation of the indicated
                                  option
          WILL (option code)  251 Indicates the desire to begin
                                  performing, or confirmation that
                                  you are now performing, the
                                  indicated option
          WON't (option code) 252 Indicates the refusal to perform,
                                  or continue performing, the
                                  indicated option.
          DO (option code)    253 Indicates the request that the
                                  other party perform, or
                                  confirmation that you are expecting
                                  the other party to perform, the

    [Page 14]                                                         Postel

    RFC 764, IEN 148                                               June 1980
                                               Telnet Protocol Specification

                                  indicated option.
          DON'T (option code) 254 Indicates the demand that the
                                  other party stop performing,
                                  or confirmation that you are no
                                  longer expecting the other party
                                  to perform, the indicated option.
          IAC                 255 Data Byte 255.

    CONNECTION ESTABLISHMENT

       The TELNET TCP connection is established between the user's port U
       and the server's port L.  The server listens on its well known port L
       for such connections.  Since a TCP connection is full duplex and
       identified by the pair of ports, the server can engage in many
       simultaneous connections involving it's port L and different user
       ports U.

       Port Assignment

          When used for remote user access to service hosts (i.e., remote
          terminal access) this protocol is assigned server port 23 (27
          octal).  That is L=23.

    Postel                                                         [Page 15]