Telnet Echo Option(2)

　　If either party desires himself to echo characters to the other party　or for the other party to echo characters to him, that party gives　the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes)　for acceptance of the option. If the request to operate the　connection in echo mode is refused, then the connection continues to　operate in non-echo mode. If the request to operate the connection　in echo mode is accepted, the connection is operated in echo mode.

　　RFC857May 1983

　　After a connection has been changed to echo mode, either party may　demand that it revert to non-echo mode by giving the appropriate　DON'T ECHO or WON'T ECHO command (which the other party must confirm　thereby allowing the connection to operate in non-echo mode). Just　as each direction of the TELNET connection may be put in remote　echoing mode independently, each direction of the TELNET connection　must be removed from remote echoing mode separately.

　　Implementations of the echo option, as implementations of all other　TELNET options, must follow the loop preventing rules given in the　General Considerations section of the TELNET Protocol Specification.

　　Also, so that switches between echo and non-echo mode can be made　with minimal confusion (momentary double echoing, etc.), switches in　mode of operation should be made at times precisely coordinated with　the reception and transmission of echo requests and demands. For　instance, if one party responds to a DO ECHO with a WILL ECHO, all　data characters received after the DO ECHO should be echoed and the　WILL ECHO should immediately precede the first of the echoed　characters.

　　The echoing option alone will normally not be sufficient to effect　what is commonly understood to be remote computer echoing of　characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD option　will normally have to be invoked in conjunction with the ECHO option　to effect character-at-a-time remote echoing.

　　6. A Sample Implementation of the Option

　　The following is a description of a possible implementation for a　simple user system called "UHOST".

　　A possible implementation could be that for each user terminal, the　UHOST would keep three state bits: whether the terminal echoes for　itself (UHOST ECHO always) or not (ECHO mode possible), whether the　(human) user prefers to operate in ECHO mode or in non-ECHO mode, and　whether the connection from this terminal to the server is in ECHO or　non-ECHO mode. We will call these three bits P(hysical), D(esired),　and A(ctual).

　　When a terminal dials up the UHOST the P-bit is set appropriately,　the D-bit is set equal to it, and the A-bit is set to non-ECHO. The　P-bit and D-bit may be manually reset by direct commands if the user　so desires. For example, a user in Hawaii on a "full-duplex"　terminal, would choose not to operate in ECHO mode, regardless of the　preference of a mainland server. He should direct the UHOST to　change his D-bit from ECHO to non-ECHO.

　　When a connection is opened from the UHOST terminal to a server, the　RFC857May 1983　UHOST would send the server a DO ECHO command if the MIN (with　non-ECHO less than ECHO) of the P- and D-bits is different from the　A-bit. If a WON'T ECHO or WILL ECHO arrives from the server, the　UHOST will set the A-bit to the MIN of the received request, the　P-bit, and the D-bit. If this changes the state of the A-bit, the　UHOST will send off the appropriate acknowledgment; if it does not,　then the UHOST will send off the appropriate refusal if not changing　meant that it had to deny the request (i.e., the MIN of the P-and　D-bits was less than the received A-request).

　　If while a connection is open, the UHOST terminal user changes either　the P-bit or D-bit, the UHOST will repeat the above tests and send　off a DO ECHO or DON'T ECHO, if necessary. When the connection is　closed, the UHOST would reset the A-bit to indicate UHOST echoing.

　　While the UHOST's implementation would not involve DO ECHO or DON'T　ECHO commands being sent to the server except when the connection is　opened or the user explicitly changes his echoing mode, bigger hosts　might invoke such mode switches quite frequently. For instance,　while a line-at-a-time system were running, the server might attempt　to put the user in local echo mode by sending the WON'T ECHO command　to the user; but while a character-at-a-time system were running, the　server might attempt to invoke remote echoing for the user by sending　the WILL ECHO command to the user. Furthermore, while the UHOST will　never send a WILL ECHO command and will only send a WON'T ECHO to　refuse a server sent DO ECHO command, a server host might often send　the WILL and WON'T ECHO commands.