RFC 856: Telnet Binary Transmission (original) (raw)

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

INTERNET STANDARD

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

Postel & Reynolds [Page 1]

RFC 856 May 1983

  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

Postel & Reynolds [Page 2]

RFC 856 May 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.

Postel & Reynolds [Page 3]

RFC 856 May 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.

Postel & Reynolds [Page 4]