Telnet Binary Transmission(2)

　　6. Implementation Suggestions

　　It is foreseen that implementations of the binary transmission option　will choose to refuse some other options (such as the EBCDIC　transmission option) while the binary transmission option is in　RFC856May 1983　effect. However, if a pair of hosts can understand being in binary　transmission mode simultaneous with being in, for example, echo mode,　then it is all right if they negotiate that combination.

　　It should be mentioned that the meanings of WON'T and DON'T are　dependent upon whether the connection is presently being operated in　binary mode or not. Consider a connection operating in, say, EBCDIC　mode which involves a system which has chosen not to implement any　knowledge of the binary command. If this system were to receive a DO　TRANSMIT-BINARY, it would not recognize the TRANSMIT-BINARY option　and therefore would return a WON'T TRANSMIT-BINARY. If the default　for the WON'T TRANSMIT-BINARY were always NVT ASCII, the sender of　the DO TRANSMIT-BINARY would expect the recipient to have switched to　NVT ASCII, whereas the receiver of the DO TRANSMIT-BINARY would not　make this interpretation.

　　Thus, we have the rule that when a connection is not presently　operating in binary mode, the default (i.e., the interpretation of　WON'T and DON'T) is to continue operating in the current mode,　whether that is NVT ASCII, EBCDIC, or some other mode. This rule,　however, is not applied once a connection is operating in a binary　mode (as agreed to by both ends); this would require each end of the　connection to maintain a stack, containing all of the encoding-method　transitions which had previously occurred on the connection, in order　to properly interpret a WON'T or DON'T. Thus, a WON'T or DON'T　received after the connection is operating in binary mode causes the　encoding method to revert to NVT ASCII.

　　It should be remembered that a TELNET connection is a two way　communication channel. The binary transmission mode must be　negotiated separately for each direction of data flow, if that is　desired.

　　Implementation of the binary transmission option, as is the case with　implementations of all other TELNET options, must follow the loop　preventing rules given in the General Considerations section of the　TELNET Protocol Specification.

　　Consider now some issues of binary transmission both to and from　both a process and a terminal:

　　a. Binary transmission from a terminal.

　　The implementer of the binary transmission option should　consider how (or whether) a terminal transmitting over a TELNET　connection with binary transmission in effect is allowed to 　generate all eight bit characters, ignoring parity 　considerations, etc., on input from the terminal.

　　RFC856May 1983

　　b. Binary transmission to a process.

　　The implementer of the binary transmission option should consider how (or whether) all characters are passed to a 　process receiving over a connection with binary transmission in effect. As an example of the possible problem, TOPS-20　intercepts certain characters (e.g., ETX, the terminal　control-C) at monitor level and does not pass them to the process.

　　c. Binary transmission from a process.

　　The implementer of the binary transmission option should consider how (or whether) a process transmitting over a　connection with binary transmission in effect is allowed to　send all eight bit characters with no characters intercepted by　the monitor and changed to other characters. An example of　such a conversion may be found in the TOPS-20 system where　certain non-printing characters are normally converted to a　Circumflex (up-arrow) followed by a printing character.

　　d. Binary transmission to a terminal.

　　The implementer of the binary transmission option should　consider how (or whether) all characters received over a　connection with binary transmission in effect are sent to a　local terminal. At issue may be the addition of timing characters normally inserted locally, parity calculations, and any normal code conversion.