Telnet Binary Transmission

Once a connection is in binary mode, a received WON'T or DON'T reverts the encoding to NVT ASCII rather than to a prior mode. Tracking a full stack of prior encoding transitions was judged too complex to require of implementers.

The binary option exists to provide a binary transmission path within Telnet without requiring a higher-level protocol such as FTP. The IAC prefix mechanism naturally supports this by allowing both sides to agree to interpret transmitted bytes as raw binary data.

The meaning of WON'T and DON'T is context-dependent: when the connection is not in binary mode, they mean 'continue in the current mode' (not necessarily NVT ASCII), to avoid confusion when a non-implementing host refuses a DO TRANSMIT-BINARY while already in EBCDIC or another encoding.

Implementations may choose to refuse certain other options (e.g., the EBCDIC transmission option) while binary transmission is in effect, though simultaneous operation of compatible options (such as echo mode with binary mode) is permissible if both hosts support it.

When receiving binary data into a process, the OS may intercept certain control characters (e.g., ETX/Control-C on TOPS-20) and not pass them to the process, potentially breaking transparent binary delivery; implementers must consider this.

When sending binary data from a process, the OS may silently convert certain non-printing characters (e.g., TOPS-20 converts some to a Circumflex followed by a printable character), which violates transparent binary transmission; implementers must account for this.

When sending binary data to a terminal, locally inserted timing characters, parity calculations, and code conversions may alter the data stream; implementers must decide how to handle these transformations in binary mode.

A connection is operated in binary transmission mode only when one party has requested it and the other has acknowledged it; unilateral assertion is not sufficient.

Binary transmission mode must be negotiated separately for each direction of data flow if bidirectional binary transfer is desired; there is no single-negotiation shortcut for both directions.

Implementations of the binary transmission option must follow the loop-preventing rules given in the General Considerations section of the Telnet Protocol Specification.

The default state is WON'T TRANSMIT-BINARY and DON'T TRANSMIT-BINARY; the connection is not operated in binary mode unless explicitly negotiated.

IAC followed by an undefined Telnet command in binary mode has the same meaning as IAC NOP; however, IAC followed by an undefined command should not normally be sent in binary mode.

The TRANSMIT-BINARY Telnet option is assigned option code 0. This option enables 8-bit binary data transmission between Telnet endpoints.

registry

IAC DO TRANSMIT-BINARY (IAC 253 0): the sender requests that the remote party start transmitting characters to be interpreted as 8-bit binary data.

IAC DON'T TRANSMIT-BINARY (IAC 254 0): if binary mode is active, demands the sender revert to NVT ASCII; if not active, demands the sender continue in the current mode.

IAC WILL TRANSMIT-BINARY (IAC 251 0): the sender requests permission to begin transmitting characters to be interpreted as 8-bit binary data by the receiver.

IAC WON'T TRANSMIT-BINARY (IAC 252 0): if binary mode is active, demands reversion to NVT ASCII; if not active, refuses to enter binary mode and demands continuation of the current mode.

In binary transmission mode, a non-IAC-prefixed byte is interpreted as 8-bit binary data. IAC followed by IAC represents the single 8-bit value 255 (decimal). IAC followed by a valid Telnet command retains its command meaning even in binary mode.