Discussion of Telnet Protocol
RFC 139

Document Type RFC - Unknown (May 1971; No errata)
Updated by RFC 158
Updates RFC 137
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 139 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      T. O'Sullivan
Request for Comments: 139                                       Raytheon
NIC: 6717                                                     7 May 1971

                     Discussion of TELNET Protocol

   The attached discussion is an extension of RFC 137, NIC #6717, and is
   presented to provide useful background to designers and implementers
   to help them interpret the proposed Protocol and evaluate it in
   preparation for further discussion at the Atlantic City meetings.

   While the views in the discussion represent those of various TELNET
   committee members, they should not be interpreted as being the agreed
   view of committee.  They are the author's understanding of some of
   the arguments and background to the PROTOCOL proposed in the TELNET
   PROTOCOL recommendations.

   *  See Footnotes to attached discussion for changes to RFC 137.

Discussion of TELNET PROTOCOL

   The use of a standard, network-wide, intermediate representation of
   terminal code between sites eliminates the need for using and serving
   sites to keep information about the characteristics of each other's
   terminals and terminal handling conventions, 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
         control 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 to transmit 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 mapping
   for each case.  The information would require constant maintenance as
   new hosts were added to the network.

O'Sullivan                                                      [Page 1]
RFC 139              Discussion of TELNET Protocol            7 May 1971

   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 every one of the 128
   ASCII codes, plus (for full user power) selected control signals
   (either of a TELNET control nature, or of a special terminal nature
   such as break or attention).

   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 the 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 TTY 33 and 35.

         a. Representing lower-case output.

         b. Providing users with shift and shift lock signals.

      3. Incorporating editing capability in TELNET.

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

               kill print

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

   In early discussions, there was pressure to get a simple statement of
   protocol out early to permit early use of selected systems.  The
   counter pressure to provide a richer set of protocol in the first
   release was also present.  Work started in the direction of the
   latter, but the complexities introduced were not necessary for early
   use of the network.  The proposed solution to the TELNET protocol
   problem seems to provide a mechanism for a minimum implementation (to
   be discussed later) while providing a basis for developing richer
   sets of protocol for present and future use in terminal applications,
   process-process communications, and use by other conventions to pass
   data or control information.

O'Sullivan                                                      [Page 2]
RFC 139              Discussion of TELNET Protocol            7 May 1971

   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
Show full document text