Telnet issues(1)

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

　　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 provides its own, but it borders on the　impossible to undo echoing in a terminal which has automatic echoing　built into it.

　　Our proposed specification would use the present ECHO and NO ECHO　commands as follows: ECHO, when sent by the server to the user, would　mean 'I'll echo to you' ECHO, when sent by the user to the server,　would mean 'You echo to me'. NO ECHO, when sent by the server to the　user, would mean 'I'll not echo to you'; NO ECHO, when sent by the　user to the server, would mean 'Don't you echo to me'. These are, of　course, nearly the same meanings that the commands currently have,　although most current implementations seem to invert the server-to-user meanings.