diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc856.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc856.txt')
-rw-r--r-- | doc/rfc/rfc856.txt | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc856.txt b/doc/rfc/rfc856.txt new file mode 100644 index 0000000..92aec04 --- /dev/null +++ b/doc/rfc/rfc856.txt @@ -0,0 +1,227 @@ + +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] + |