Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-11+1


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
 Any comments should be promptly directed to me via the Network
 Information Center (Ident = JBP) or by phone (213) 825-2368 or by
                            Jon Postel
                            SPADE Group
                            3804 Boelter Hall
                            Los Angeles, California 90024

Postel [Page 1] RFC 318 Telnet Protocol April 1972


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

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.


 The purpose of Telnet Protocol is to provide a standard method of
 interfacing terminals devices at one site to processes at another
 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
 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
 Note that all code values are given in decimal.

Postel [Page 3] RFC 318 Telnet Protocol April 1972


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


 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


 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
 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] RFC 318 Telnet Protocol April 1972


 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.


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


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

Postel [Page 8] 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
 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] 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
 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."


 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

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] RFC 318 Telnet Protocol April 1972

       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] 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
    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
          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] 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
 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.
    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] RFC 318 Telnet Protocol April 1972

    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.


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


 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.


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

/data/webs/external/dokuwiki/data/pages/rfc/rfc318.txt · Last modified: 2000/04/19 22:31 (external edit)