Network Working Group
`Request for Comments: 854
`
`Obsoletes: NIC 18639
`
`J. Postel
`J. Reynolds
`ISI
`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.
`
`When a TELNET connection is first established, each end is
`1.
`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]
`
`Juniper Ex. 1054-p. 1
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 2
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 3
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 4
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 5
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 6
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 7
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 8
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 9
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 10
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1054-p. 11
`Juniper v Implicit
`
`

`

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