Telnet issues(2)

　　In our specification, whenever a connection is opened both server and　user assume that the user is echoing locally. If the user would, in　fact, prefer the server to echo, the user could send off an ECHO　command. Similarly, if the server prefers to do the echoing (for　instance, because the server system is optimized for very interactive　echoing), the server could send off an ECHO command. Neither is　required to do anything, it is only a matter of preference. Upon　receipt of either command by either party, if that is an admissible　mode of operation the recipient should begin operating in that mode,　and if such operation reflects a change in mode, it should respond　with the same command to confirm that (and when) the changeover took　place. If the received command request an inadmissible mode of　operation, then the command's inverse should be sent as a refusal　(this must be NO ECHO, since neither party can refuse a change into　NO ECHO). To state these rules more formally:

　　1) Both server and user assume that a connection is initially in　NO ECHO mode.

　　2) Neither party can refuse a request to change into NO ECHO mode.

　　3) Either party may send an unsolicited command only to request a　change in mode.

　　4) A party only changes its echo mode when it receives an　admissible request.

　　5) When a command is received, the party replies with its echo　mode, unless it did not have to change mode to honor the　request.

　　Several properties of this scheme are worthy of note:

　　1) NO ECHO is retained as the nominal connection mode. A　connection will work in ECHO mode only when both parties agree　to operate that way.

　　2) The procedure cannot loop. Regardless of which party (or both)　initiates a change, or in what time order, there are at most　three commands sent between the parties [2].

　　3) Servers are free to specify their preferred mode of operation.　Thus, human, or machine, users do not have to learn the proper　mode for each server.

　　Three Principles

　　Let us mention the general principles we alluded to at the beginning　of this note. The principles are: default implementation, negotiated　options and symmetry. The principle of default implementation merely　states that for all options, defaults are declare which must be　implemented. It is this principle which leads us to seek out the　'minimum' for each option (to keep the required burden on everybody　as small as possible), and prevents loops in protocol. The principle　of negotiated options merely states that options must be agreed upon　by all (both) parties concerned. It is this principle which dictated　the positive/negative acknowledgement scheme. The principle of　symmetry merely states that neither party should have to 'know'　whether it is the server or the user. Our scheme, as described thus　far, is not totally symmetrical we will consider this matter in a　later section.

　　The ECHOING scheme we have described, together with the principles　stated above, form the heart of our comments on the TELNET protocol.

　　The remainder of this note consists of further ways in which the　protocol can be expanded on the whole, these suggestions are all　really only applications and development of the principles we have　already put forward. However, the fecundity of these expansions, and　the 'good feel' they have, make us yet more convinced of the '　rightness' of our original proposals.　Thus far, we have made a simple, concrete suggestion that we believe　should be immediately sanctioned. Looking beyond that proposal,　however, has suggestion a large number of further, more ambitious　changes. The remainder of this RFCdescribes ideas which we don't　feel have the immediacy of the proposal above, but should,　nonetheless, be kept in mind if the network community decides to　embark on revamping the protocol.

　　Synchronization