Browse Prior Art Database

Discussion of Telnet Protocol (RFC0139)

IP.com Disclosure Number: IPCOM000007194D
Original Publication Date: 1971-May-07
Included in the Prior Art Database: 2002-Mar-05
Document File: 12 page(s) / 26K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T.C. O'Sullivan: AUTHOR

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 13% of the total text.

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