path: root/doc/rfc/rfc318.txt

Network Working Group                                         Jon Postel
Request for Comments: 318                                       UCLA-NMC
NIC: 9348                                                  April 3, 1972
References: RFC 139, 158, and NIC 7104


                            Telnet Protocol


   At the October 1971 Network Working Group Meeting, I promised to
   promptly produce a document which clearly and succinctly specified
   and explained the Official Telnet Protocol.  This document fails to
   meet any part of that promise.  This document was not produced
   promptly.  This document is neither clear nor succinct.  There is NO
   Official Telnet Protocol.

   The following pages present my understanding of the ad hoc Telnet
   protocol.  There are some who have serious questions about this
   protocol.  The proposed changes to the protocol are given in Section
   IV.

   Any comments should be promptly directed to me via the Network
   Information Center (Ident = JBP) or by phone (213) 825-2368 or by
   mail.

                              Jon Postel
                              SPADE Group
                              3804 Boelter Hall
                              UCLA
                              Los Angeles, California 90024





















Postel                                                          [Page 1]
^L
RFC 318                     Telnet Protocol                   April 1972


I.  DEFINITION OF THE NETWORK VIRTUAL TERMINAL

   The Network Virtual Terminal (NVT) is a bi-directional character
   device.  The characters are represented by 8 bit codes.  The NVT has
   no timing characteristics.  The character codes 0 through 127 are the
   USASCII codes.  (Note all code values are given in decimal.)  The
   codes 128 through 255 are used for special control signals.  The NVT
   is described as having a printer and a keyboard.  The printer
   responds to incoming data and the keyboard produces outgoing data.

The Printer

   The NVT printer has an unspecified carriage width (common values are
   40, 72, 80, 120, 128, 132).  The printer can produce representations
   of all 95 USASCII graphics (codes 32 through 126).  Of the 33 USASCII
   control codes (0 through 31 and 127) the following 8 have specific
   meaning to the NVT printer.

   NAME                  CODE    MEANING

   NULL (NUL)            0       A no operation.

   BELL (BEL)            7       Produces an audible or visible signal.

   Back Space (BS)       8       Backspaces the printer one character
                                 position.

   Horizontal Tab (HT)   9       Moves the printer to next horizontal
                                 tab stop.

   Line Feed (LF)        10      Moves the printer to next line (keeping
                                 the same horizontal position).

   Vertical Tab (VT)     11      Moves the printer to the next vertical
                                 tab stop.

   Form Feed (FF)        12      Moves the printer to the top of the
                                 next page.

   Carriage Return (CR)  13      Moves the printer to the left margin
                                 of the current line.

   The remaining USASCII codes (1 through 6, 14 through 31, and 127) do
   not cause the NVT printer to take any action.







Postel                                                          [Page 2]
^L
RFC 318                     Telnet Protocol                   April 1972


The Keyboard

   The NVT Keyboard has keys or key combinations or key sequences for
   generating all of the 128 USASCII codes.  Note that although there
   are codes which have no effect on the NVT printer, the NVT Keyboard
   is capable of generating these codes.

The End of the Line Convention

   The end of a line of text shall be indicated by the character
   sequence Carriage Return Line Feed (CR, LF).  This convention applies
   to both the sending (Keyboard) and receiving (Printer)  (virtual)
   mechanisms.

Break and Reverse Break

   The Telnet control signals provide a BREAK signal which can be used
   to simulate the use of the break or attention or interrupt button
   found on most terminals.  This signal has no effect on the NVT.  When
   the BREAK Telnet control signal is used from server to user it is
   sometimes called "reverse break".  Such a reverse break has no effect
   on the NVT.

II.  DEFINITION OF TELNET PROTOCOL

   The purpose of Telnet Protocol is to provide a standard method of
   interfacing terminals devices at one site to processes at another
   site.

   The Telnet Protocol is built up from three major substructures, first
   the Initial Connection Protocol (ICP), second the Network Virtual
   Terminal (NVT), and third the Telnet control signals described
   herein.

   Telnet user and server processes follow the ICP to establish
   connections.  The term "Logger" has been associated with the set of
   processes in the serving system which respond to the ICP and perform
   the initial interactions e.g. obtain a name and password.  The ICP is
   defined and the initial socket number and byte size parameters are
   defined in "Current Network Protocols" (NIC #7104).

   The data transmitted between the user and server programs (and vice
   versa) is treated as a character stream with embedded control
   signals.

   Note that all code values are given in decimal.





Postel                                                          [Page 3]
^L
RFC 318                     Telnet Protocol                   April 1972


TELNET CONTROL SIGNALS

   NAME             CODE    MEANING

   DATA MARK        128     Used to mark a point in the data stream.
                            Used in conjunction with INS.  See SYNCH.

   BREAK            129     User-to-Server:  Has the same meaning to
                            the server as the "Break," "Interrupt," or
                            "Attention" button found on many terminals.

                            Server-to-User:  Has the same meaning to
                            to use as the "reverse break" used with
                            some terminals.

   NOP              130     No Operation.

   NO ECHO          131     User-to-Server:  Asks the server not to
                            return Echos of the transmitted data.

                            Server-to-User:  States that the server is
                            not sending echos of the transmitted data.
                            Sent only as a reply to ECHO or NO ECHO,
                            or to end the hide your input.

   ECHO             132     User-to-Server:  Asks the server to send
                            Echos of the transmitted data.

                            Server-to User:  States that the server is
                            sending echos of the transmitted data.
                            Sent only as a reply to ECHO or NO ECHO.

   Hide your input  133     The intention is that a server will send
                            this signal to a user system which is
                            echoing locally (to the user) when the user
                            is about to type something secret (e.g. a
                            password).  In this case, the user system
                            is to suppress local echoing or overprint
                            the input (or something) until the server
                            sends a NOECHO signal.  In situations where
                            the user system is not echoing locally,
                            this signal must not be sent by the server.

   INS              ---     This is the "Interrupt on Send" signal,
                            defined by the Host-to-Host protocol and
                            implemented by the Network Control Program
                            (NCP).  See SYNCH.




Postel                                                          [Page 4]
^L
RFC 318                     Telnet Protocol                   April 1972


   SYNCH            ---     This is a condition indicated by the
                            combination of the DATA MARK and the INS.

                            User-to-Server:  The Server is to examine
                            the input data stream looking for a DATA
                            MARK signal; if a DATA MARK is found, the
                            server must not process further until an
                            INS is received.  If the server receives an
                            INS, it is required to examine the data
                            stream at once, taking any appropriate
                            action on "break type" characters (e.g.
                            etx, sub, BREAK), up to a DATA MARK signal
                            and thereupon continue its normal processing.
                            The passed over characters may be discarded.

                            Server-to-User:  If the user finds a DATA
                            MARK in the data stream, it must wait for
                            an INS.  If the user receives an INS, it
                            must examine and discard characters up to
                            and including a DATA MARK.

DATA TYPES

   Telnet normally deals in ASCII characters, but there are provisions
   for escaping to other code sets.  If one of these escapes is used, it
   is undefined (here) whether or not the Telnet signals still have
   meaning or even how to return to the ASCII set:  The Telnet signals
   used to indicate a change of code set are:

                      CODE          MEANING

                      160           ASCII - Standard Telnet
                      161           Transparent
                      162           EBCDIC

USER TELNET SIGNALS

   The following signals are to be available to the human user to cause
   the user Telnet to take the indicated action.

   Transmit Now         -  Transmit all data entered and locally
                           buffered now.  Intended to be used with line
                           mode.

   Suppress end-of-line -  Transmit all data entered and locally
                           buffered now, and do not transmit the
                           end-of-line immediately following this signal.




Postel                                                          [Page 5]
^L
RFC 318                     Telnet Protocol                   April 1972


STANDARD TELNET IMPLEMENTATION

   Using Site

   1)  User is able to enter and transmit all ASCII codes

   2)  User is able to cause the Telnet signals BREAK, SYNCH, ECHO and
       NOECHO to be transmitted.

   3)  Provides for the User Telnet signals, (e.g. Transmit Now).

   4)  Implements the CR LF end-of-line convention.

   5)  Provides local echo for local user terminals.

   6)  Correctly processes the Telnet signals BREAK, SYNCH, NOP, ECHO,
       NOECHO, and Hide Your Input received from the server.

   Serving Site:

   1)  Provides a mapping between ASCII and the local character set.

   2)  Correctly processes the Telnet signals BREAK, SYNCH, NOP, NOECHO,
       and ECHO.

   3)  Implements the CR LF end-of-line convention.

   4)  Assumes the using site provides echoing.  May provide a server
       echo mode.

MINIMUM TELNET IMPLEMENTATION

   Using Site:

   1)  User must be able to enter and transmit all ASCII codes.

   2)  Ignore and delete all Telnet signals from the serving site.

   3)  Provide local echo for local user terminals.

   4)  Implements CR LF end-of-line convention.

   5)  Provide for the User Telnet signals.








Postel                                                          [Page 6]
^L
RFC 318                     Telnet Protocol                   April 1972


   Serving Site:

   1)  Provide a mapping between ASCII and the local character set.

   2)  Ignore and Delete all Telnet signals from the using site.

   3)  Assume the using site provides echoing.

   4)  Implements the CR LF end-of-line convention.

III.  DISCUSSION OF TELNET PROTOCOL

   The use of a standard, network-wide, intermediate representation of
   terminal code between sites is intended to eliminate the need for
   using and serving sites to keep information about the characteristics
   of each other's terminals and terminal handling conventions.  This
   approach can be successful, but only if the user, the using site, and
   the serving site assume certain responsibilities.

   1.  The serving site must specify how the intermediate code will be
       mapped by it into the terminal codes that are expected at that
       site.

   2.  The user must be familiar with that mapping.

   3.  The using site must provide some means for the user to enter all
       of the intermediate codes, and as a convenience, special Telnet
       signals, as well as specify for the user how the signals from the
       serving site will be presented at the user terminal.

   Other schemes were considered but rejected.  For example, a proposal
   that the using site be responsible for translating to and from the
   code expected by the serving site was rejected since it required that
   the using site keep tables of all serving site codes and provide a
   mapping for each case.  The information would require constant
   maintenance as new hosts were added to the network.

Character Set

   Since it is not known how the current or future sites will specify
   the mapping between the network-wide standard code (7 bit ASCII in an
   8 bit field) and the codes expected from their own terminals, it
   seems necessary to permit the user to cause transmission of every one
   of the 128 ASCII codes, plus (for full user power) selected signals
   (either of a Telnet control nature, or of a special terminal nature
   such as break or attention).





Postel                                                          [Page 7]
^L
RFC 318                     Telnet Protocol                   April 1972


   There was strong feeling about the importance of the user/system
   interface at the using site, but equally strong feeling that this
   problem is one of local implementation and should reflect the using
   site installation philosophy rather than be subject to network-wide
   standards.  Some topics of consideration in this area are:

      1.  How to represent special graphics, not available at the using
          site, at the user's terminal.

      2.  Treatment of upper/lower case problem on upper case only
          devices.

          a.  Representing lower-case output.

          b.  Providing users with shift and shiftlock signals.

      3.  Incorporating editing capability in Telnet.

      4.  Extending user options in Network mode not available to local
          users, e.g., hold output or kill print.

      5.  Permit users to specify how keyboard input is to the
          translated, e.g., let a character from the terminal cause a
          specified string to be sent by the user's Telnet.

   The proposed solution to the Telnet Protocol problem seems to provide
   a mechanism for a minimum implementation while providing a basis for
   developing richer sets or protocol for present and future use in
   terminal applications, process-process communications, and use by
   other conventions to pass data or control information.

   The understanding that ASCII be used as a network-wide code has been
   established for some time.  Its use in Telnet provided a problem with
   respect to the limitation of a maximum character set of 128.  Some
   systems provide for more than this number in their operation, and
   therefore, as serving sites, cannot map on a one-for-one basis.

   Each such serving site could probably provide a reasonably useful
   character set, including all system control signals, by mapping 128
   of its codes and just not provide a network user access to the other
   codes.  However, any character left out might later be used in a
   major application at that site as a special control signal.  This
   could result in denying network users the facility offered by that
   application.  Serving sites are, therefore, encouraged to provide a
   full mapping between the ASCII code and the code used on the serving
   system.  This may require that the server specify two character ASCII
   sequences which map to single characters in the servers character
   set.



Postel                                                          [Page 8]
^L
RFC 318                     Telnet Protocol                   April 1972


   Notice that there are some ASCII codes which have no effect on the
   NVT printer.  These codes must be transmitted over the network when
   output by the serving process or by entered by the user.

End of Line Convention

   The representation of the end of a physical line at a terminal is
   implemented differently on different network hosts.  For example,
   some use a return (or new line) key, the terminal hardware both
   returns the carriage or printer to start of line and feeds the paper
   to the next line.  In other implementations, the user hits carriage
   return and the hardware returns carriage while the software sends the
   terminal a line feed.  The network-wide representation is carriage
   return followed by line feed.  It represents the physical formatting
   that is being attempted, and is to be interpreted and appropriately
   translated by both using site and serving site.

      EXAMPLE:  A Multics user is working, through the network, on some
      serving site host.  In the course of the session the user has
      numerous occasions to hit New Line on his Model 37 TTY.  Each time
      the Multics system is awakened by a New Line interrupt, the line
      of buffered characters is passed to Telnet where it is scanned for
      special characters.  If none is found, carriage return followed by
      line feed is inserted where New Line was entered, and the line is
      turned over the NCP for transmission.  Correspondingly, when the
      Multics Telnet finds the carriage return line feed sequence in the
      data stream coming from the serving site, the two characters are
      replaced with the appropriate New Line code which is sent to the
      terminal.

   Telnet defines the end of a line to be indicated by the ASCII
   character pair CR LR.  Several of the real devices in the world have
   only a single new line (NL) function.  Several of the computer
   systems have in some programs used the CR and LF functions to have
   semantic meaning larger than the format effect they provide.
   Further, several computer systems allow the CR and LF functions to be
   used separately (e.g., such that a line may be overprinted).  One
   problem, for those Telnet (user) programs required to map the NVT
   into a device which only has a NL function, is how is the CR LF to be
   dealt with.  One solution is to examine the character following the
   CR.  If an LF is found, then perform the NL function; if anything
   else is found then back space to the beginning of the line.  Another
   problem is the case of a computer system which locally uses period,
   ".", to cause the new line function and which uses, in some programs,
   CR and LF for semantically significant operations.  Suppose the user
   Telnet sends the sequence CR LF.  Does this mean "new line" or the
   "CR operation" followed by the "LF operation "?  A solution to this
   problem it to require that Telnet programs send a CR NOT intended to



Postel                                                          [Page 9]
^L
RFC 318                     Telnet Protocol                   April 1972


   be part of a CR LF pair as a CR NUL pair.  Then the receiving program
   can always hold a CR and examine the next character to determine if a
   new line function is intended.  This solution is strongly
   recommended.

   One other question arises here,  "Is it permitted to send the Telnet
   signal NOP (code 130) between a CR and a LF when these are intended
   to signify new line?"  The answer is "yes, the NOP signal may occur
   anywhere in the data stream."

Echoing

   The decision to have the assumed condition for echo be that the using
   site will provide any echo necessary for its terminals was taken
   because of the difficulties faced by some installations that cannot
   turn off their echo or that have terminals that print locally as a
   result of key strokes.  Serving sites could take the position "have
   user turn echo off," but this seems an unnecessary burden on the
   user.  In addition, some serving sites may choose not to supply any
   echo service, in which case the no echo assumption will supply a
   network-wide condition, while other assumptions would give a mixed
   starting condition.

   The convention of using "ECHO," "NO ECHO" signals seems to fill both
   the requirements for dynamic echo control and for a minimum
   implementation of Telnet Protocol.  Note that when the user request
   ECHO or NO ECHO the server replies by switching to the desired mode
   (and possibly returning the signal for the new mode), or by
   continuing in the current mode and returning the signal for the
   current mode.  The server never spontaneously sends an ECHO or NO
   ECHO signal.  Except that a NOECHO may be used to cancel a HIDE YOUR
   INPUT.

Hide Your Input

   The HIDE YOUR INPUT signal presents some difficulty in that it is
   unclear how much is to be hidden.  The server site usually knows how
   long the secret is but the user Telnet in general does not.
   Furthermore, if the user site cannot suppress the local echoing,
   there is a difficult implementation problem.  One possibility is for
   the using site to overprint a full line with a mask, then have the
   user type his secret on the mask.  If the secret were longer than one
   line, the use of the mask should be repeated.

   The use of HIDE YOUR INPUT can be avoided altogether by having the
   serving site send a mask (which it knows to be just long enough) on
   which the user is to type the secret information.




Postel                                                         [Page 10]
^L
RFC 318                     Telnet Protocol                   April 1972


      EXAMPLE:

         1.  Default assumption is user site is echoing

         2.  Server-to User:  Password Please CR LF

         3.  Server-to-User:  XXXXCRIIIIICRMMMMCR NUL

         4.  User-to-Server:  "password" CR LF

         5.  Server-to-User:  Ready CR LF

Breaks and Attentions

   There is a special control signal on some terminals that has no
   corresponding bit pattern in ASCII, but is transmitted by a special
   electrical signal.  This control signal is Attn on a 2741 and Break
   on a Teletype.  This signal is represented by the Telnet control
   signal BREAK.  There is a corresponding control signal for use from
   serving sites to using sites for reverse break.  Notice, however,
   that the NVT is a bi-directional character device, thus there is no
   need to "turn the line around".

   Some systems treat the Break as an extra code available for use in
   conjunction with the data stream.  For example, one system uses Break
   as a special editing code meaning "delete the current line to this
   point."  In these cases, the code may simply be inserted in the data
   stream with no special additional action by the user.

   Other systems use Break or Attn in special interrupt fashion, to mean
   stop processing the application and give me the supervisor, or cancel
   the present job, etc.  (Other systems which inspect input on a
   character at a time basis use normal characters for this purpose,
   such as <etx>.) In these cases, because of differences in the ways
   both serving and using sites operate, it is necessary to take a route
   in addition to the normal Telnet data stream to indicate that the
   special control signal is embedded in the data stream.

   Example -- Problem:

      The PDP-10 normally will, when it fills its input buffer, continue
      to accept characters from a terminal examining each to see if it
      is a control character, then act on it if it is or throw it away
      if it is not.

      Since the Telnet server at the serving site is at the mercy of the
      NCP with respect to controlling the bunching, and therefore,
      arrival at the Telnet of bursts of characters, Telnet



Postel                                                         [Page 11]
^L
RFC 318                     Telnet Protocol                   April 1972


      implementations might be expected to choke off flow to the buffers
      until they are ready to accept characters without throwing them
      away.

      Under this condition, the serving process might be outputting to
      the using terminal, the input buffers at the server fill up, (with
      user generated characters) and <etx> get stuck (at the user's
      site) in the data stream that has been choked off.

   A similar problem could occur with Multics or some IBM system as a
   line at a time server.  The user at a using site gets his process at
   the serving site into an output loop and wants to break the process
   without having to release his Telnet connection.  The buffers clog
   the connection, transmission is choked off, and the <etx>, Break, or
   other user control signal gets stuck in the pipeline.

   Example -- Solution:

      The user at the using site knows he is entering a special control
      signal (Break, Attn, <etx>, etc.) and follows it with a SYNCH.
      (The local instructions at using sites for accomplishing this may
      differ from site to site.)

         User to Using Site Telnet

            Send SYNCH.

         Using Site Telnet to Serving Site Telnet:

            DATA MARK in Data Stream.

         Using Site Telnet to Using Site NCP:

            Send an INS.

         Serving Site NCP to Telnet Server:

            Interrupt "INS received".

         Serving Site Telnet:

            Examines the input data stream (looking for special control
            signals) until it sees DATA MARK then resumes normal
            handling.

            Thus, depending on the server's local implementation to
            provide adequate service, a special handling of the data
            stream can be invoked whenever an INS is received in order



Postel                                                         [Page 12]
^L
RFC 318                     Telnet Protocol                   April 1972


            to get to the special character.  When it sees DATA MARK, it
            recognizes it as a synchronization point and knowing that
            the special character has been passed on, strips the DATA
            MARK from the data stream and returns to normal mode.

            If the DATA MARK arrives before the INS, the serving site
            should not process the data stream further until an INS is
            received.

   This approach to handling selected special characters or signals
   relieves the using Telnet processes from having to recognize the
   special serving site characters, as well as from having to know how
   the serving site wants to handle them.  At the same time, the
   procedure requires only a minimum level of user understanding of the
   serving site.  This seems appropriate, since the Telnet ASCII
   conventions are providing a Network Virtual Terminal, not a Network
   Virtual User.

   Notice that the correct order is (1) special character or signal
   (e.g. BREAK or <etx>), then (2) SYNCH.

User Telnet Signals

   The ability of the user to cause the using site Telnet to send any
   combination of ASCII characters in a string, and only that
   combination, is viewed as important to the user utility of the Telnet
   ASCII conventions.  Because of this, some user sites may find it
   necessary to provide special local Telnet signals from the human user
   to the using site Telnet.

      Example:

      A user on a line at a time system (Multics, System 360, GCOS,
      etx.), which require an end of line signal before processing the
      user's input, is working through the Network on a serving site
      that operates a character at a time.  The application is a
      debugging aid that permits the user to type in "location=" to
      which it will respond with n where n represents the current
      contents of that location.  The serving site process does not
      expect to see the "location=" followed by a carriage return line
      feed sequence.  The user at the using site should be able to type
      in the location, follow it with a signal (to the user Telnet) to
      suppress the end of line convention, followed by the end of line
      signal, and expect the "location=" to be transmitted immediately
      without an end of line sequence being transmitted to the server.






Postel                                                         [Page 13]
^L
RFC 318                     Telnet Protocol                   April 1972


      Example:

      In another case, a using site has decided that it is convenient to
      accumulate four characters at a time and transmit them to the
      serving site, unless an end of line signal is observed, in which
      case the end of line sequence is sent preceded by whatever number
      of characters have been accumulated (presumably three or less).
      In the same debugging application, the address is such that the
      end does not correspond with the four character buffer
      demarcation.  The user should have the ability to enter a code for
      "transmit immediately" in place of the end of line signal in order
      to preserve neat formatting, and expect the address to be sent to
      the serving site.

   Telnet Signals have been discussed and those introduced to date are
   probably sufficient for an implementation of Telnet ASCII convention.

Terminology

   ASCII          - The USASCII character set as defined in NIC # 7104.
                    In Telnet Protocol, where eight bit codes are used
                    the lower half of the code set is defined to be
                    ASCII.

   echoing        - The display of a character entered is called echoing.
                    There are two modes in which this happens.  If
                    the device used to enter characters displays the
                    character before (or as) it transmits the character
                    to the computer the echoing mode is called "local
                    echo."  If, on the other hand, the device transmits
                    the entered character to the computer without
                    displaying it and the computer then transmits a
                    character to the device for the echo display, this
                    echoing mode is called "remote echo."

   character mode - In this mode of operation Telnet transmits each
                    character as soon as possible.  Generally speaking,
                    character mode is used when all of the using terminal,
                    using system, and serving system are operating
                    in a remote echo mode.  The echos to the user
                    entered characters are transmitted from the serving
                    system (i.e., over the network).

   line mode      - In this mode of operation Telnet transmits groups
                    of characters which constitute lines.  Generally
                    speaking, this mode is used when one or more of
                    the using terminal, using system, or serving




Postel                                                         [Page 14]
^L
RFC 318                     Telnet Protocol                   April 1972


                    system is operating in a local echo mode.  The
                    echos to the user entered characters are not
                    transmitted over the network).

   full duplex    - This term indicates a transmission procedure using
                    a four wire connection, which permits simultaneous
                    transmission in both directions.

   half duplex    - This term indicates a transmission procedure using
                    a two wire connection, which requires that data be
                    transmitted in only one direction at at time.

   Note that half duplex devices usually are also local echo but that
   full duplex devices may be either local echo or remote echo.

IV.  PROPOSED CHANGES TO TELNET PROTOCOL

   The changes suggested here are not my ideas, thus the presentation may
   be faulty.  I welcome RFC or other communication suggesting other
   changes or better arguments for and against these changes.

Echoing

   It is proposed to delete from Telnet the control signals ECHO, NOECHO,
   and HIDE YOUR INPUT.  For Server systems which do not provide echoing,
   these commands are useless.  For server systems which do provide
   echoing experience has shown that the control is most effectively
   provided by server system commands.

Data Types

   It is proposed to delete all mention of data types from Telnet.
   Either the character stream is ASCII or its not a Telnet
   communication.  If it is really necessary to change the data type, a
   command in ASCII could be sent in the data stream.

Minimum Implementation

   It is proposed that the minimum implementation require the user Telnet
   to allow the user to send and the server Telnet to correctly process
   all the Telnet control signals.










Postel                                                         [Page 15]
^L
RFC 318                     Telnet Protocol                   April 1972


   The  work on Telnet Protocol has involved many people.  This document
   is taken from RFC's #139 and #158 by Tom O'Sullivan.  Others who
   have served on committees are:

                    Bob Bressler           MIT-DMCG

                    Will Crowther          BBN

                    Bob Long               SDC

                    Alex McKenzie          BBN

                    John Melvin            SRI-ARC

                    Bob Metcalfe           MIT-DMCG

                    Ed Meyer               MIT-Multics

                    Tol O'Sullivan         Raytheon

                    Mike Padlipsky         Mit-Multics

                    Jon Postel             UCLA-NMC

                    Bob Sundberg           Harvard

                    Joel Winett            LL

                    Steve Wolfe            UCLA-CCN







        [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Kelly Tardif, Viaginie 10/99]













Postel                                                         [Page 16]
^L