summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc729.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc729.txt')
-rw-r--r--doc/rfc/rfc729.txt186
1 files changed, 186 insertions, 0 deletions
diff --git a/doc/rfc/rfc729.txt b/doc/rfc/rfc729.txt
new file mode 100644
index 0000000..5ad2943
--- /dev/null
+++ b/doc/rfc/rfc729.txt
@@ -0,0 +1,186 @@
+Network Working Group Dave Crocker, Rand-ISD
+Request for Comments: 729 (Dcrocker at Rand-Unix)
+NlC: 40306 13 May l977
+
+
+
+
+ TELNET Byte Macro Option
+
+
+1. Command name and code:
+
+ BM 19
+
+2. Command Meanings:
+
+ IAC WILL BM
+
+ The sender of this command REQUESTS or AGREES to use the BM
+ option, and will send sing1e data characters which are to be
+ interpreted as if longer data strings had been sent.
+
+ IAC WON'T BM
+
+ The sender of this option REFUSES to send single data
+ characters which are to be interpreted as if longer data
+ strings had been sent.
+
+ IAC DO BM
+
+ The sender REQUESTS or AGREES to have the other side (send of
+ WILL BM) issue send single data characters which are to be
+ interpreted as if longer data strings had been sent.
+
+ IAC DON'T BM
+
+ The sender REFUSES to allow the other side to send single data
+ characters which are to be interpreted as if longer data
+ strings had been sent.
+
+ IAC SB BM <DEFINE> <macro byte> <count>
+ <expansion string> IAC SE
+ where:
+
+ <macro byte> is the data byte actually to be sent across
+ the network; it may NOT be Telnet IAC (decimal 255).
+
+
+RFC #729 Telnet Byte Macro Option Page 2
+
+
+
+ <count> is a one-byte binary number, indicating how many
+ <expansion string> characters follow, up to the ending IAC
+ SE, but not including it.
+
+ <expansion string> is a string of one or more Telnet ASCII
+ characters and/or commands, which the <macro byte> is to
+ represent; any character may occur within an <expansion
+ string>.
+
+ The indicated <macro byte> will be sent instead of the
+ indicated <expansion string>. The receiver of the <macro byte>
+ (the sender of the DO BM) is to behave EXACTLY as if the
+ <expansion string> of bytes had instead been received from the
+ network. This interpretation is to occur before any other
+ Telnet interpretations, unless the <macro byte> occurs as part
+ of a BM subcommand; in this case no special interpretation is
+ to be made.
+
+ Note that the effect of a particular <macro byte> may be
+ negated by reseting it to "expand" into itself.
+
+ <DEFINE> is decimal 01.
+
+
+ IAC SB BM <ACCEPT> <macro byte> IAC SE
+
+ The receiver of the <DEFINE> for <macro byte> accepts the
+ requested definition and will perform the indicating expansion
+ whenever a <macro byte> is received and is not part of a BM
+ subcommand.
+
+ <ACCEPT> is decimal 02.
+
+
+ IAC SB BM <REFUSE> <macro byte> <REASON> IAC SE
+
+ The receive of the <DEFINE> for <macro byte> refuses to
+ perform the indicated translation from <macro byte> to
+ <expansion string> either because the particular <macro byte>
+ is not an acceptable choice or because the length of the
+ <expansion string> exceeds available storage.
+
+ <REFUSE> is decimal 03.
+
+ <REASON> may be
+
+ <BAD CHOICE> which is decimal 01; or
+
+ <TOO LONG> which is decimal 02.
+
+
+RFC #729 Telnet Byte Macro Option Page 3
+
+
+
+
+ IAC SB BM <LITERAL> <macro byte> IAC SE
+
+ The <macro byte> is to be treated as real data, rather than as
+ representative of the <expansion string>
+
+ <LITERAL> is decimal 03.
+
+
+
+
+3. Default:
+
+ WON'T BM -- DON'T BM
+
+ No reinterpretation of data is allowed.
+
+4. Motivation for the option:
+
+ Subcommands for Telnet options currently require a minimum of five
+ characters to be sent over the network (i.e., IAC SB <Option name>
+ IAC SE). For sub-commands which are employed infrequently, in
+ absolute numbers and in relation to normal data, this overhead is
+ tolerable. In other cases, however, it is not. For example, data
+ which is sent in a block-oriented fashion may need a "block
+ separator" mark. If blocks are commonly as small as five or ten
+ bytes, then most of the cross-net data will be control information.
+ The BM option is intended as a simple data compression technique,
+ to remove this overhead from the communication channel.
+
+
+5. Description of the option
+
+ The option is enabled through the standard Telnet Option
+ negotiation process. Afterwards, the SENDER of data (the side which
+ sends the IAC WILL BM) is free to define and use mappings between
+ single and multiple NOT characters. Except for the ability to offer
+ a blanket refusal, the receiver of data has no control over the
+ definition and use of mappings.
+
+ The sender (of the WILL BM) is prohibited from using or redefining
+ a <macro byte> until it has received an <ACCEPT> or <REFUSE>, in
+ reply to a <DEFINE>.
+
+ NOTE: The Telnet command character IAC (decimal 255) may be a
+ member of an <expansion string> but is the ONLY character which may
+ NOT be defined as a <macro byte>. ALL OTHER Telnet command
+ characters use IAC as a preface and therefore occupy a SEPARATE
+ portion of the data space than do regular data bytes.
+
+RFC #729 Telnet Byte Macro Option Page 4
+
+
+
+ With the exception of IAC, data transfered as part of BM
+ subcommands are NOT to be interpreted. They are to be taken only as
+ their normal character values. This avoids the problem of
+ distinguishing between a character which is to be taken as a <macro
+ byte>, and interpreted as its corresponding <expansion string>, and
+ that same character to be taken as its usual Telnet NVT value. In
+ all other cases, however, <macro byte>s are to be interpreted
+ immediately, as if the <expansion string> had actually been sent
+ across the network. Expanded strings are not subject to
+ reinterpretation, so that recursive definitions cannot be made.
+
+ The <count> in the <DEFINE> subcommand allows the receiver to
+ allocate storage. IAC interpretation is not over-ridden during BM
+ subcommands so that IAC SE will continue to safely terminate
+ malformed subcommands. To include IAC as part of a <DEFINE>, the
+ string "IAC IAC" must be sent.
+
+ The BM option is notably inefficient with regard to problems during
+ <macro byte> definition and use of <macro byte>s as real data. It
+ is expected that relatively few <macro byte>s will be defined and
+ that they will represent relatively short strings. Since the Telnet
+ data space between decimal 128 and decimal 254 is not normally
+ used, except by implementations employing the original Telnet
+ protocol, it is recommended that <macro byte>s normally be drawn
+ from that pool.