Browse Prior Art Database

Telnet issues (RFC0435)

IP.com Disclosure Number: IPCOM000004922D
Original Publication Date: 1973-Jan-05
Included in the Prior Art Database: 2001-Jul-12
Document File: 11 page(s) / 23K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Cosell: AUTHOR [+2]

Abstract

This RFC discusses a number of TELNET related issues which have been bothering us [1]. The basic, central issue we started from was that of echoing. We worked downward from our difficulties to discover the basic principles at the root of our unhappiness, and from there worked back upwards to design a scheme which we believe to be better. In this note we will discuss both the alternate scheme and its underlying principles.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 15% of the total text.

Network Working Group B. Cosell Request for Comment: 435 BBN-NET NIC: 13675 D. Walden Category: TELNET, Protocols, Echoing BBN-NET References: 318, 357 5 January 1973

TELNET Issues

This RFC discusses a number of TELNET related issues which have been bothering us [1]. The basic, central issue we started from was that of echoing. We worked downward from our difficulties to discover the basic principles at the root of our unhappiness, and from there worked back upwards to design a scheme which we believe to be better. In this note we will discuss both the alternate scheme and its underlying principles.

As something of a non sequitur, before discussing echoing we feel it expedient to dismiss one possible stumbling block, outright. HIDE YOUR INPUT may or may not be a good idea, this question not concerning us at the moment. Whatever the case, the issue of hiding input is certainly separable from that of echoing. We, therefore, strongly recommend that a STOP HIDING YOUR INPUT command be sanctioned to replace the multiplexing of this function on the NO ECHO command. Once this has been done, the pair of commands HIDE YOUR INPUT and STOP HIDING YOUR INPUT can be kept or discarded together, and we can discuss the issue of echoing independently of them.

Echoing

The basic observation that we made regarding echoing was that servers seem to be optimized to best handle terminals which either do their own echoing or do not, but not both. Therefore, the present TELNET echoing conventions, which prohibit the server from initiating a change in echo mode, seemed overly confining. The servers are burdened with users who are in the 'wrong' mode, in which they might not otherwise have to be, and users, both human and machine, are burdened with remembering the proper echoing mode, and explicitly setting it up, for all the different servers. It is our understanding that this prohibition was imposed on the servers to prevent loops from developing because of races which can arise when the server and user both try to set up an echo mode simultaneously. We will describe a method wherein both parties can initiate a change of echo mode and show that the method does not loop.

Cosell Walden [Page 1]

RFC 435 TELNET Issues 5 January 1973

This alternate specification relies on three primary assumptions. First as above, the server, as well as the user, should be able to suggest the echo mode. Second, all terminals must be able to provide their own echoes, either internally or by means of the local Host. Third, all servers must be able to operate in a mode which assumes that a remote terminal is providing its own echoes. Both of these last two result from the quest for a universal, minimal basis upon which to build. It is fairly easy for a Host which normally supplies echoes to disable the appropriate code, but it will difficult for a Host which does not do echoing to integrate such routines into its system similarly, it is easier for a local Host to supply echoes to a terminal which cannot ...