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.