Telnet Binary Transmission
An option that lets Telnet send and receive raw 8-bit data instead of only NVT ASCII text.
Postel, J. and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, DOI 10.17487/RFC0856, May 1983, <https://www.rfc-editor.org/info/rfc856>.
@misc{rfc856,
series = {Request for Comments},
number = 856,
howpublished = {RFC 856},
publisher = {RFC Editor},
doi = {10.17487/RFC0856},
url = {https://www.rfc-editor.org/info/rfc856},
author = {J. Postel and J. Reynolds},
title = {{Telnet Binary Transmission}},
pagetotal = 4,
year = 1983,
month = may,
} RFC text
Contents
Network Working Group J. Postel
Request for Comments: 856 J. Reynolds
ISI
Obsoletes: NIC 15389 May 1983
TELNET BINARY TRANSMISSION
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
TRANSMIT-BINARY 0
2. Command Meanings
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.
IAC WON'T TRANSMIT-BINARY
If the connection is already being operated 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. If the connection is not
already being operated in binary transmission 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
(i.e., the sender of the data demands to continue transmitting
characters in its present mode).
A connection is being operated in binary transmission mode only
when one party has requested it and the other has acknowledged it.
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).
IAC DON'T TRANSMIT-BINARY
If the connection is already being operated 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
being operated in binary transmission mode, the sender of this
command DEMANDS that the sender of data continue transmitting
characters which are to be interpreted in the present mode.
A connection is being operated in binary transmission mode only
when one party has requested it and the other has acknowledged it.
3. Default
WON'T TRANSMIT-BINARY
DON'T TRANSMIT-BINARY
The connection is not operated in binary mode.
4. Motivation for the Option
It is sometimes useful to have available a binary transmission path
within TELNET without having to utilize one of the more efficient,
higher level protocols providing binary transmission (such as the
File Transfer Protocol). The use of the IAC prefix within the basic
TELNET protocol provides the option of binary transmission in a
natural way, requiring only the addition of a mechanism by which the
parties involved can agree to INTERPRET the characters transmitted
over a TELNET connection as binary data.
5. Description of the Option
With the binary transmission option in effect, the receiver should
interpret characters received from the transmitter which are not
preceded with IAC as 8 bit binary data, with the exception of 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 additional characters required to complete the command) is still
the command even with the binary transmission option in effect. IAC
followed by a character which is not a defined TELNET command has the
same meaning as IAC followed by NOP, although an IAC followed by an
undefined command should not normally be sent in this mode.
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
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.
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.
ISO Plain Language
On this page
§1Why Binary Transmission
RFC 856 defines the TRANSMIT-BINARY option with code 0. It provides a way to have a binary path within Telnet without using a higher-level protocol such as FTP. The existing IAC mechanism in Telnet makes this a natural extension.
Sometimes you want to send data that isn't just text. This option gives Telnet a safe way to do that without moving to another program.
§2Negotiating Binary Mode
The option is negotiated using four commands: IAC WILL TRANSMIT-BINARY (requests or confirms sending binary data), IAC WON'T TRANSMIT-BINARY, IAC DO TRANSMIT-BINARY (requests or confirms that the other side sends binary data), and IAC DON'T TRANSMIT-BINARY. A connection is in binary mode only when one side has requested it and the other has acknowledged it. The default is WON'T and DON'T (not binary).
If binary mode is already in effect, receiving WON'T or DON'T demands a return to standard NVT ASCII. If not in binary mode, they mean continue in the present mode.
One side asks to switch to binary, the other agrees. Either side can ask to stop, which sends both back to plain text. The agreement applies separately to each direction of data flow.
| Command | Meaning |
|---|---|
| IAC WILL TRANSMIT-BINARY | Sender requests or confirms it will send 8-bit binary data |
| IAC WON'T TRANSMIT-BINARY | If in binary mode, demands return to NVT ASCII; otherwise refuses |
| IAC DO TRANSMIT-BINARY | Requests or confirms the other side should send binary data |
| IAC DON'T TRANSMIT-BINARY | If in binary mode, demands return to NVT ASCII; otherwise demands current mode |
§3How Data Is Interpreted
When binary mode is in effect, characters not preceded by IAC are interpreted as 8-bit binary data. The exception is IAC IAC, which represents the 8-bit data value 255. IAC followed by a real Telnet command remains a command; IAC followed by an undefined command has the same meaning as IAC NOP (though not normally sent).
In binary mode, almost everything is treated as raw data. To send the special control byte itself as data, you send it twice.
§4Implementation Considerations
Binary mode must be negotiated separately for each direction. The loop-preventing rules of the Telnet protocol apply. Implementations may refuse other options (such as EBCDIC) while in binary mode, though combinations are possible if both hosts agree.
The rule for reverting: once binary mode is agreed, a WON'T or DON'T always reverts to NVT ASCII (not to the previous mode), to avoid needing a stack of transitions. Implementers must also consider whether terminals and processes can actually pass all 8-bit characters, as some systems intercept or convert certain characters.
Each direction needs its own agreement. Stopping binary mode always goes back to plain text, not to some other encoding. Not all systems can safely handle every possible 8-bit value.