diff options
Diffstat (limited to 'doc/rfc/rfc857.txt')
| -rw-r--r-- | doc/rfc/rfc857.txt | 284 |
1 files changed, 284 insertions, 0 deletions
diff --git a/doc/rfc/rfc857.txt b/doc/rfc/rfc857.txt new file mode 100644 index 0000000..e18adba --- /dev/null +++ b/doc/rfc/rfc857.txt @@ -0,0 +1,284 @@ + +Network Working Group J. Postel +Request for Comments: 857 J. Reynolds + ISI +Obsoletes: NIC 15390 May 1983 + + TELNET ECHO OPTION + + +This RFC specifies a standard for the ARPA Internet community. Hosts on +the ARPA Internet are expected to adopt and implement this standard. + +1. Command Name and Code + + ECHO 1 + +2. Command Meanings + + IAC WILL ECHO + + The sender of this command REQUESTS to begin, or confirms that it + will now begin, echoing data characters it receives over the + TELNET connection back to the sender of the data characters. + + IAC WON'T ECHO + + The sender of this command DEMANDS to stop, or refuses to start, + echoing the data characters it receives over the TELNET connection + back to the sender of the data characters. + + IAC DO ECHO + + The sender of this command REQUESTS that the receiver of this + command begin echoing, or confirms that the receiver of this + command is expected to echo, data characters it receives over the + TELNET connection back to the sender. + + IAC DON'T ECHO + + The sender of this command DEMANDS the receiver of this command + stop, or not start, echoing data characters it receives over the + TELNET connection. + +3. Default + + WON'T ECHO + + DON'T ECHO + + No echoing is done over the TELNET connection. + +4. Motivation for the Option + + +Postel & Reynolds [Page 1] + + + +RFC 857 May 1983 + + + The NVT has a printer and a keyboard which are nominally + interconnected so that "echoes" need never traverse the network; that + is to say, the NVT nominally operates in a mode where characters + typed on the keyboard are (by some means) locally turned around and + printed on the printer. In highly interactive situations it is + appropriate for the remote process (command language interpreter, + etc.) to which the characters are being sent to control the way they + are echoed on the printer. In order to support such interactive + situations, it is necessary that there be a TELNET option to allow + the parties at the two ends of the TELNET connection to agree that + characters typed on an NVT keyboard are to be echoed by the party at + the other end of the TELNET connection. + +5. Description of the Option + + When the echoing option is in effect, the party at the end performing + the echoing is expected to transmit (echo) data characters it + receives back to the sender of the data characters. The option does + not require that the characters echoed be exactly the characters + received (for example, a number of systems echo the ASCII ESC + character with something other than the ESC character). When the + echoing option is not in effect, the receiver of data characters + should not echo them back to the sender; this, of course, does not + prevent the receiver from responding to data characters received. + + The normal TELNET connection is two way. That is, data flows in each + direction on the connection independently; and neither, either, or + both directions may be operating simultaneously in echo mode. There + are five reasonable modes of operation for echoing on a connection + pair: + + + <---------------- + + Process 1 Process 2 + ----------------> + Neither end echoes + + + <---------------- + \ + Process 1 / Process 2 + ----------------> + One end echoes for itself + + + + + + +Postel & Reynolds [Page 2] + + + +RFC 857 May 1983 + + + + <---------------- + \ + Process 1 / Process 2 + ----------------> + One end echoes for the other + + + <---------------- + \ / + Process 1 / \ Process 2 + ----------------> + Both ends echo for themselves + + + <---------------- + \ / + Process 1 / \ Process 2 + ----------------> + One end echoes for both ends + + This option provides the capability to decide on whether or not + either end will echo for the other. It does not, however, provide + any control over whether or not an end echoes for itself; this + decision must be left to the sole discretion of the systems at each + end (although they may use information regarding the state of + "remote" echoing negotiations in making this decision). + + It should be noted that if BOTH hosts enter the mode of echoing + characters transmitted by the other host, then any character + transmitted in either direction will be "echoed" back and forth + indefinitely. Therefore, care should be taken in each implementation + that if one site is echoing, echoing is not permitted to be turned on + at the other. + + As discussed in the TELNET Protocol Specification, both parties to a + full-duplex TELNET connection initially assume each direction of the + connection is being operated in the default mode which is non-echo + (non-echo is not using this option, and the same as DON'T ECHO, WON'T + ECHO). + + 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. + + +Postel & Reynolds [Page 3] + + + +RFC 857 May 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 + + +Postel & Reynolds [Page 4] + + + +RFC 857 May 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. + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 5] + |