Discussion of Telnet Protocol(1)

　　Network Working Group T. O'Sullivan

　　Request for Comments: 139 Raytheon

　　NIC: 6717 7 May 1971

　　Discussion of TELNETProtocol

　　The attached discussion is an extension of RFC137, 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 RFC137.

　　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.

　　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.