home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc856.txt < prev    next >
Text File  |  1991-10-16  |  9KB  |  228 lines
  1.  
  2. Network Working Group                                          J. Postel
  3. Request for Comments: 856                                    J. Reynolds
  4.                                                                      ISI
  5. Obsoletes: NIC 15389                                            May 1983
  6.  
  7.                        TELNET BINARY TRANSMISSION
  8.  
  9.  
  10. This RFC specifies a standard for the ARPA Internet community.  Hosts on
  11. the ARPA Internet are expected to adopt and implement this standard.
  12.  
  13. 1.  Command Name and Code
  14.  
  15.    TRANSMIT-BINARY      0
  16.  
  17. 2.  Command Meanings
  18.  
  19.    IAC WILL TRANSMIT-BINARY
  20.  
  21.       The sender of this command REQUESTS permission to begin
  22.       transmitting, or confirms that it will now begin transmitting
  23.       characters which are to be interpreted as 8 bits of binary data by
  24.       the receiver of the data.
  25.  
  26.    IAC WON'T TRANSMIT-BINARY
  27.  
  28.       If the connection is already being operated in binary transmission
  29.       mode, the sender of this command DEMANDS to begin transmitting
  30.       data characters which are to be interpreted as standard NVT ASCII
  31.       characters by the receiver of the data.  If the connection is not
  32.       already being operated in binary transmission mode, the sender of
  33.       this command REFUSES to begin transmitting characters which are to
  34.       be interpreted as binary characters by the receiver of the data
  35.       (i.e., the sender of the data demands to continue transmitting
  36.       characters in its present mode).
  37.  
  38.       A connection is being operated in binary transmission mode only
  39.       when one party has requested it and the other has acknowledged it.
  40.  
  41.    IAC DO TRANSMIT-BINARY
  42.  
  43.       The sender of this command REQUESTS that the sender of the data
  44.       start transmitting, or confirms that the sender of data is
  45.       expected to transmit, characters which are to be interpreted as 8
  46.       bits of binary data (i.e., by the party sending this command).
  47.  
  48.    IAC DON'T TRANSMIT-BINARY
  49.  
  50.       If the connection is already being operated in binary transmission
  51.       mode, the sender of this command DEMANDS that the sender of the
  52.       data start transmitting characters which are to be interpreted as
  53.  
  54.  
  55. Postel & Reynolds                                               [Page 1]
  56.  
  57.  
  58.  
  59. RFC 856                                                         May 1983
  60.  
  61.  
  62.       standard NVT ASCII characters by the receiver of the data (i.e.,
  63.       the party sending this command).  If the connection is not already
  64.       being operated in binary transmission mode, the sender of this
  65.       command DEMANDS that the sender of data continue transmitting
  66.       characters which are to be interpreted in the present mode.
  67.  
  68.       A connection is being operated in binary transmission mode only
  69.       when one party has requested it and the other has acknowledged it.
  70.  
  71. 3.  Default
  72.  
  73.    WON'T TRANSMIT-BINARY
  74.  
  75.    DON'T TRANSMIT-BINARY
  76.  
  77.       The connection is not operated in binary mode.
  78.  
  79. 4.  Motivation for the Option
  80.  
  81.    It is sometimes useful to have available a binary transmission path
  82.    within TELNET without having to utilize one of the more efficient,
  83.    higher level protocols providing binary transmission (such as the
  84.    File Transfer Protocol).  The use of the IAC prefix within the basic
  85.    TELNET protocol provides the option of binary transmission in a
  86.    natural way, requiring only the addition of a mechanism by which the
  87.    parties involved can agree to INTERPRET the characters transmitted
  88.    over a TELNET connection as binary data.
  89.  
  90. 5.  Description of the Option
  91.  
  92.    With the binary transmission option in effect, the receiver should
  93.    interpret characters received from the transmitter which are not
  94.    preceded with IAC as 8 bit binary data, with the exception of IAC
  95.    followed by IAC which stands for the 8 bit binary data with the
  96.    decimal value 255.  IAC followed by an effective TELNET command (plus
  97.    any additional characters required to complete the command) is still
  98.    the command even with the binary transmission option in effect.  IAC
  99.    followed by a character which is not a defined TELNET command has the
  100.    same meaning as IAC followed by NOP, although an IAC followed by an
  101.    undefined command should not normally be sent in this mode.
  102.  
  103. 6.  Implementation Suggestions
  104.  
  105.    It is foreseen that implementations of the binary transmission option
  106.    will choose to refuse some other options (such as the EBCDIC
  107.    transmission option) while the binary transmission option is in
  108.  
  109.  
  110.  
  111.  
  112. Postel & Reynolds                                               [Page 2]
  113.  
  114.  
  115.  
  116. RFC 856                                                         May 1983
  117.  
  118.  
  119.    effect.  However, if a pair of hosts can understand being in binary
  120.    transmission mode simultaneous with being in, for example, echo mode,
  121.    then it is all right if they negotiate that combination.
  122.  
  123.    It should be mentioned that the meanings of WON'T and DON'T are
  124.    dependent upon whether the connection is presently being operated in
  125.    binary mode or not.  Consider a connection operating in, say, EBCDIC
  126.    mode which involves a system which has chosen not to implement any
  127.    knowledge of the binary command.  If this system were to receive a DO
  128.    TRANSMIT-BINARY, it would not recognize the TRANSMIT-BINARY option
  129.    and therefore would return a WON'T TRANSMIT-BINARY.  If the default
  130.    for the WON'T TRANSMIT-BINARY were always NVT ASCII, the sender of
  131.    the DO TRANSMIT-BINARY would expect the recipient to have switched to
  132.    NVT ASCII, whereas the receiver of the DO TRANSMIT-BINARY would not
  133.    make this interpretation.
  134.  
  135.    Thus, we have the rule that when a connection is not presently
  136.    operating in binary mode, the default (i.e., the interpretation of
  137.    WON'T and DON'T) is to continue operating in the current mode,
  138.    whether that is NVT ASCII, EBCDIC, or some other mode.  This rule,
  139.    however, is not applied once a connection is operating in a binary
  140.    mode (as agreed to by both ends); this would require each end of the
  141.    connection to maintain a stack, containing all of the encoding-method
  142.    transitions which had previously occurred on the connection, in order
  143.    to properly interpret a WON'T or DON'T.  Thus, a WON'T or DON'T
  144.    received after the connection is operating in binary mode causes the
  145.    encoding method to revert to NVT ASCII.
  146.  
  147.    It should be remembered that a TELNET connection is a two way
  148.    communication channel.  The binary transmission mode must be
  149.    negotiated separately for each direction of data flow, if that is
  150.    desired.
  151.  
  152.    Implementation of the binary transmission option, as is the case with
  153.    implementations of all other TELNET options, must follow the loop
  154.    preventing rules given in the General Considerations section of the
  155.    TELNET Protocol Specification.
  156.  
  157.    Consider now some issues of binary transmission both to and from
  158.    both a process and a terminal:
  159.  
  160.       a. Binary transmission from a terminal.
  161.  
  162.          The implementer of the binary transmission option should
  163.          consider how (or whether) a terminal transmitting over a TELNET
  164.          connection with binary transmission in effect is allowed to
  165.          generate all eight bit characters, ignoring parity
  166.          considerations, etc., on input from the terminal.
  167.  
  168.  
  169. Postel & Reynolds                                               [Page 3]
  170.  
  171.  
  172.  
  173. RFC 856                                                         May 1983
  174.  
  175.  
  176.       b. Binary transmission to a process.
  177.  
  178.          The implementer of the binary transmission option should
  179.          consider how (or whether) all characters are passed to a
  180.          process receiving over a connection with binary transmission in
  181.          effect.  As an example of the possible problem, TOPS-20
  182.          intercepts certain characters (e.g., ETX, the terminal
  183.          control-C) at monitor level and does not pass them to the
  184.          process.
  185.  
  186.       c. Binary transmission from a process.
  187.  
  188.          The implementer of the binary transmission option should
  189.          consider how (or whether) a process transmitting over a
  190.          connection with binary transmission in effect is allowed to
  191.          send all eight bit characters with no characters intercepted by
  192.          the monitor and changed to other characters.  An example of
  193.          such a conversion may be found in the TOPS-20 system where
  194.          certain non-printing characters are normally converted to a
  195.          Circumflex (up-arrow) followed by a printing character.
  196.  
  197.       d. Binary transmission to a terminal.
  198.  
  199.          The implementer of the binary transmission option should
  200.          consider how (or whether) all characters received over a
  201.          connection with binary transmission in effect are sent to a
  202.          local terminal.  At issue may be the addition of timing
  203.          characters normally inserted locally, parity calculations, and
  204.          any normal code conversion.
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Postel & Reynolds                                               [Page 4]
  227.  
  228.