

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 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,

 

 

 

 

Postel & Reynolds                                               [Page 1]



RFC 854                                                         May 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 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.

      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

 

 

Postel & Reynolds                                               [Page 2]



RFC 854                                                         May 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.)

 

   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 detailed 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" 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 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.

 

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

 

 

 

 

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

         that a "line" is terminated (i.e., when the "New Line" key is

         typed by the user).  When this occurs, the attached (local)

 

 

Postel & Reynolds                                               [Page 5]



RFC 854                                                         May 1983

 

 

         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.

 

      Note that the symmetry of the TELNET model requires that there is

      an NVT at each end of the TELNET connection, at least

      conceptually.

 

   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

 

 

Postel & Reynolds                                               [Page 6]



RFC 854                                                         May 1983

 

 

      below.  These standard representations have standard, but not

      required, meanings (with the exception that the Interrupt Process

      (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 a

      local user is obliged to provide the same function to 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 server systems which provide this

         function, that there may be buffers external to the system (in

 

 

 

 

Postel & Reynolds                                               [Page 7]



RFC 854                                                         May 1983

 

 

         the 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) to the user system.

 

      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

      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.

 

 

 

Postel & Reynolds                                               [Page 8]



RFC 854                                                         May 1983

 

 

      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.

 

         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.

 

         If TCP indicates more Urgent data after the DM is found, it can

         only be because of a subsequent Synch.  TELNET should continue

         the special handling of the data stream until another 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

      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.

 

 

Postel & Reynolds                                               [Page 9]



RFC 854                                                         May 1983

 

 

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

 

 

 

 

 

 

 

 

Postel & Reynolds                                              [Page 10]



RFC 854                                                         May 1983

 

 

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

 

         Note that "CR LF" or "CR NUL" is required in both directions

 

 

Postel & Reynolds                                              [Page 11]



RFC 854                                                         May 1983

 

 

         (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, nonetheless, 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.

 

      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.

 

 

 

Postel & Reynolds                                              [Page 12]



RFC 854                                                         May 1983

 

 

      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 68 (104 octal) 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 124 (174 octal) 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.

 

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

 

 

 

Postel & Reynolds                                              [Page 13]



RFC 854                                                         May 1983

 

 

   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

                                 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.

 

 

 

 

 

 

 

Postel & Reynolds                                              [Page 14]



RFC 854                                                         May 1983

 

 

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 its 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 & Reynolds                                              [Page 15]



