1 files changed, 854 insertions, 0 deletions

diff --git a/misc/rfc854-telnet.txt b/misc/rfc854-telnet.txt
new file mode 100644
index 0000000..e794bf7
--- /dev/null
+++ b/misc/rfc854-telnet.txt
@@ -0,0 +1,854 @@
+
+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]
+