Telnet issues(4)

　　Responding to this, we came to understand that there are only five　reasonable modes of operation for the echoing on a connection pair

　　[4]:

　　<------------------<

　　A Process 1 Process 2

　　>------------------>

　　neither end echoes

　　<------------------<

　　B Process 1 <--+ Process 2

　　^

　　>--^--------------->

　　one end echoes for itself

　　<------------------<

　　C Process 1 <--------------+ Process 2

　　^

　　>--------------^--->

　　one end echoes for the other

　　<--------------V---<

　　D Process 1 <--+ V Process 2

　　^ +--->

　　>--^--------------->

　　both ends echo for themselves

　　<-----V------------<

　　E Process 1 <--+ V Process 2

　　^ +------------>

　　>--^--------------->

　　one end echoes for both ends

　　The TENEX group suggested to us that four commands are sufficient to　deal with completely symmetric echoing. We have actually already　mentioned the four commands -- the two possible meanings for each of　ECHO and NO ECHO. Explicitly, the commands would be I'LL ECHO TO　YOU, YOU ECHO TO ME, DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.

　　Echoing is now the negotiation of two options, and the initial,　default modes are DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.

　　In the case where the server or user knows which he is, the　modification to the scheme is minimal since the commands never had　ambiguous meanings in these cases. When an 'end' truly doesn't know,　then things are a little more complicated -- for example, consider　both ends in I'LL ECHO TO YOU mode, but even then the problems are　not insurmountable.

　　Once the principle of symmetry is adopted, it is no longer possible　to use a function in two different ways. On pages 5 and 6 of RFC　318, Postel gives a description of INS and SYNC which indicates that　they are used to simulate a 'break' user-to-server, but flush the　output buffers server-to-user. Since we do believe in symmetry, we　suggest that the INS/DATA-MARK be treated the same in both directions　and that a new CLEAR YOUR BUFFER option be added.

　　Command Format

　　Extending full symmetry through the other options we have suggested,　we can now describes the compacted command format referred to　earlier.

　　Rather than having four commands for each option (I WILL, I WON'T,　YOU DO, YOU DON'T), there would be four 'prefixes' -- WILL, WON'T,　DO, DON'T -- which would be used before the single command devoted to　each option, WON'T and DON'T being the default modes. To give an　example, assume the codes for WILL and WON'T are 140 and 141, and the　codes for ECHO REMOTE and HIDE INPUT are 132 and 133. Then several　of the possible command combinations would be:

　　140 133 -- DO HIDE INPUT

　　140 132 -- DO ECHO REMOTE

　　141 132 -- WON'T ECHO REMOTE

　　141 133 -- WON'T HIDE INPUT

　　These are some of the commands that we believe should exist:

　　I WILL (140)

　　I WILL NOT (141)

　　YOU DO (142)

　　YOU DO NOT (143)

　　QUOTE (144)

　　SYNC (163)

　　SYNC REPLY (164)

　　ECHO REMOTE (132)

　　SEND A CHARACTER-AT-A-TIME (146)

　　SEND INDEPENDENT CR and LF (147)

　　SEND IN EBCDIC (162)

　　HIDE INPUT (133)

　　USE DAVIDSON'S ECHOING STRATEGY (145)

　　An important virtue of this command structure, and of our entire　viewpoint, is that Hosts need no longer even be aware of what all the　options are. If we call the mode of operation in which every　alternative is in its default state the 'NVT', then a site, of　course, must handle an NVT, but beyond that if it merely responds no　to any command it does not understand, then it can totally ignore　options it chooses not to implement. Thus, options would truly be　optional (for a change), not only to the user who may choose not to　invoke them, but also to the systems builders who may now choose not　to offer them!