RFC 856

TELNET BINARY TRANSMISSION 🎀

okay bestie, this is RFC 856 💖, and it's all about TELNET BINARY TRANSMISSION. J. Postel and J. Reynolds at ISI wrote it, and it's dated May 1983. It's a standard 👑, so hosts on the ARPA Internet are expected to adopt and implement it. It obsoletes NIC 15389, and it doesn't list any RFCs it updates ✨.

---

1. Command Name and Code 🦋

   TRANSMIT-BINARY      0

2. Command Meanings 💅

okay so the TRANSMIT-BINARY option has a few IAC commands that do different things. Here they are 🫶

IAC WILL TRANSMIT-BINARY

the sender of this command REQUESTS permission to begin transmitting, or confirms that it will now begin transmitting characters which are to be interpreted as 8 bits of binary data by the receiver of the data. it's giving "may I please" energy 🥺

IAC WON'T TRANSMIT-BINARY

if the connection is already in binary transmission mode, the sender of this command DEMANDS to begin transmitting data characters which are to be interpreted as standard NVT ASCII characters by the receiver of the data. but if the connection is not already in binary mode, the sender of this command REFUSES to begin transmitting characters which are to be interpreted as binary characters by the receiver of the data. in other words, the sender of the data demands to keep transmitting in its present mode 🙅‍♀️

a connection is only in binary transmission mode when one party has requested it and the other has acknowledged it. no solo binary mode, periodt 💜

IAC DO TRANSMIT-BINARY

the sender of this command REQUESTS that the sender of the data start transmitting, or confirms that the sender of data is expected to transmit, characters which are to be interpreted as 8 bits of binary data (i.e., by the party sending this command). the vibe is "you go first" 🌸

IAC DON'T TRANSMIT-BINARY

if the connection is already in binary transmission mode, the sender of this command DEMANDS that the sender of the data start transmitting characters which are to be interpreted as standard NVT ASCII characters by the receiver of the data (i.e., the party sending this command). if the connection is not already in binary mode, the sender of this command DEMANDS that the sender of data continue transmitting characters which are to be interpreted in the present mode. 😤

again, a connection is only in binary transmission mode when one party has requested it and the other has acknowledged it ✨

3. Default 🍓

the defaults are WON'T TRANSMIT-BINARY and DON'T TRANSMIT-BINARY. with those, the connection is not operated in binary mode. simple, iconic 🧚

4. Motivation for the Option 🌈

ngl, sometimes you want a binary path inside TELNET without using one of the fancier, more efficient higher-level protocols that do binary transfer (like the File Transfer Protocol). the IAC prefix in basic TELNET already gives you binary transmission in a natural way. the only thing missing is a way for both parties to agree that they'll INTERPRET the characters sent over the TELNET connection as binary data. that's the whole glow-up 🦋✨

5. Description of the Option 💜

when the binary transmission option is in effect, the receiver should interpret characters from the transmitter that are not preceded by IAC as 8 bit binary data. the one exception is IAC followed by IAC, which stands for the 8 bit binary data with the decimal value 255 👑

IAC followed by an effective TELNET command (plus any extra characters needed to finish the command) is still a command, even with binary transmission on. bestie, commands still count 🙅‍♀️

IAC followed by a character that isn't a defined TELNET command has the same meaning as IAC followed by NOP. though an IAC followed by an undefined command should not normally be sent in this mode. (lowkey just don't do it 🙈)

6. Implementation Suggestions 🔥

it's foreseen that implementations of the binary transmission option will choose to refuse some other options (like the EBCDIC transmission option) while binary transmission is in effect. BUT if a pair of hosts can handle being in binary transmission mode at the same time as, say, echo mode, then it's all right for them to negotiate that combo. two-option besties 🫶

the meanings of WON'T and DON'T depend on whether the connection is currently operating in binary mode or not. picture this: a connection is in EBCDIC mode, and one system has chosen not to implement any knowledge of the binary command. if it received a DO TRANSMIT-BINARY, it wouldn't recognize TRANSMIT-BINARY and would send back a WON'T TRANSMIT-BINARY. now, if the default for WON'T TRANSMIT-BINARY were always NVT ASCII, the sender of DO TRANSMIT-BINARY would expect the other side to have switched to NVT ASCII, but the receiver of DO TRANSMIT-BINARY would NOT read it that way. chaos 💀

so the rule is: when a connection is not currently in binary mode, the default (the meaning of WON'T and DON'T) is to keep operating in the current mode, whether that's NVT ASCII, EBCDIC, or some other mode 🧚. this rule doesn't apply once the connection is in a binary mode (as agreed by both ends). that would mean each end keeps a stack of every encoding-method change that happened on the connection, just to correctly interpret a WON'T or DON'T. no thank you 🙅‍♀️. so a WON'T or DON'T received once the connection is in binary mode makes the encoding method go back to NVT ASCII.

remember, a TELNET connection is a two-way channel. binary transmission must be negotiated separately for each direction of data flow, if you want it in each direction 🦋

implementing the binary transmission option, like implementing every other TELNET option, must follow the loop preventing rules in the General Considerations section of the TELNET Protocol Specification 🔁

now let's talk about binary transmission to and from both a process and a terminal:

a. Binary transmission from a terminal.

the implementer should think about how (or whether) a terminal sending over a TELNET connection with binary transmission in effect is allowed to generate all eight bit characters on input, ignoring parity considerations and so on 🎀

b. Binary transmission to a process.

the implementer should think about how (or whether) all characters get passed to a process receiving over a connection with binary transmission in effect. for example, TOPS-20 intercepts certain characters (like ETX, the terminal control-C) at monitor level and does not pass them to the process. not every character makes it to the party 💀

c. Binary transmission from a process.

the implementer should think about how (or whether) a process sending over a connection with binary transmission in effect is allowed to send all eight bit characters, with none intercepted by the monitor and changed into other characters. an example of such a conversion is in TOPS-20, 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 should think about how (or whether) all characters received over a connection with binary transmission in effect are sent to a local terminal. things to consider are the addition of timing characters normally inserted locally, parity calculations, and any normal code conversion ⭐

that's the whole tea, bestie 🫶💖