RFC 139 (rfc139) - Page 2 of 11

Discussion of Telnet Protocol

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