As per Relevance of the word interpreted, we have this rfc below:

---

RFC 735 DHC RHG 3 Nov 77 42083
Telnet Byte Macro



Network Working Group David H.
RFC: #735 Rand-
NIC: #42083 (Dcrocker at Rand-Unix
Richard H.
Carnegie-Mellon
(Gumpertz at CMU-10A

Obsoletes: RFC #729 (NIC #40306) 3 November 1977

Revised TELNET Byte Macro

1. Command name and code

BM 19

2. Command Meanings

IAC WILL

The sender of this command REQUESTS or AGREES to use the
option, and will send single data characters which are to
interpreted as if replacement data strings had been sent

IAC WON'T

The sender of this option REFUSES to send single data
which are to be interpreted as if replacement data strings
been sent. Any existing BM definitions are
(i.e., reset to their original data interpretations).

IAC DO

The sender REQUESTS or AGREES to have the other side (sender
WILL BM) send single data characters which are to be
as if replacement data strings had been sent

IAC DON'T

The sender REFUSES to allow the other side to send single
characters which are to be interpreted as if replacement
strings had been sent. Any existing BM
are to be discarded










1

RFC 735 DHC RHG 3 Nov 77 42083
Telnet Byte Macro



IAC SB BM <replacement string> IAC

where

is the data byte actually to be sent across
network; it may NOT be Telnet IAC (decimal 255, but may be
other 8-bit character

is one 8-bit byte binary number, indicating how
<replacement string> characters follow, up to the ending
SE, but not including it. Note that doubled IACs in
definition should only be counted as one character per pair

<replacement string> is a string of zero or more Telnet
characters and/or commands, which the is
represent; any character may occur within a <
string>. Note, however, that an IAC in the string must
doubled, to be interpreted later as an IAC; to be
later as data byte 255, it must be quadrupled in the
<replacement string> specification

The indicated will be sent instead of the
<replacement string>. The receiver of the (the
of the DO BM) is to behave EXACTLY as if the <replacement string
string of bytes had instead been received from the network.
interpretation is to occur before any other
interpretations, unless the occurs as part of
Telnet command; in this case no special interpretation is to
made. In particular, an entire Telnet subnegotiation (i.e.
IAC SB through IAC SE) is to be considered a Telnet command
which NO replacement should be done

The effect of a particular may be negated by
it to "expand" into itself

IAC SB BM X <0> IAC SE may be used to cause X to
ignored in the data stream

is decimal 1.

IAC SB BM IAC

The receiver of the for accepts
requested definition and will perform the indicated
whenever a is received and is not part of any
Telnet command sequence





2

RFC 735 DHC RHG 3 Nov 77 42083
Telnet Byte Macro



is decimal 2.

IAC SB BM IAC

The receiver of the for refuses to
the indicated translation from to <
string> because the particular is not an
choice, the length of the <replacement string> exceeds
storage, the length of the actual <replacement string> did
match the length predicted in the , or for some
reason

is decimal 3.

may

which is decimal 1;

(for receiver's storage) which is
2;

(of actual string compared with
length in ) which is decimal 3;

(intended for use only until this
can be updated to include reasons
anticipated by the authors) which
decimal zero (0).

IAC SB BM IAC

The is to be treated as real data, rather than
representative of the <replacement string

Note that this subcommand cannot be used during
subcommands, since subcommands are defined to end with the
occurrence of "IAC SE". Including this BM subcommand within
Telnet subcommand would therefore prematurely terminate
containing subcommand

is decimal 4.

IAC SB BM IAC

The RECEIVER of the defined (i.e., the sender of
DO BM) requests the sender of to cancel
definition. is the same as for the subcommand





3

RFC 735 DHC RHG 3 Nov 77 42083
Telnet Byte Macro



The sender should (but is not required to) respond
resetting (i.e., sending an IAC SB BM <
byte> <1> IAC SE).

If the receiver absolutely insists on cancelling a given macro
the best it can do is to turn off the entire option, with IAC
BM, wait for an acknowledging IAC WONT BM and then restart
option, with IAC DO BM. This will reset all other macroes as
but it will allow the receiver to REFUSE with code BAD
if/when the foreign site attempts to redefine the macro
question

3. Default

WON'T BM -- DON'T

No reinterpretation of data bytes is done

4. Motivation for the option

Subcommands for Telnet options currently require a minimum of
characters to be sent over the network (i.e., IAC SB IAC SE). For subcommands which are employed infrequently, in
numbers and in relation to normal data, this overhead is tolerable
In other cases, however, it is not. For example, data which is
in a block- oriented fashion may need a "block separator" mark.
blocks are commonly as small as five or ten bytes, then most of
cross-net data will be control information. The BM option is
as a simple data compression technique, to remove this overhead
the communication channel

5. Description of the

The option is enabled through the standard Telnet Option
process. Afterwards, the SENDER of data (the side which sends the
WILL BM) is free to define and use mappings between single
replacement NVT characters. Except for the ability to
particular definitions, the receiver of data has no control over
definition and use of mappings

The sender (of the WILL BM) is prohibited from using or redefining
until it has received an , or DONT BM
in reply to a .

NOTE: The Telnet command character IAC (decimal 255) may be a
of a <replacement string> but is the ONLY character which may NOT
defined as a .





4

RFC 735 DHC RHG 3 Nov 77 42083
Telnet Byte Macro



Within any Telnet command (i.e., any sequence beginning with IAC
macro replacement may NOT take place. Data are to be interpreted
as their normal character values. This avoids the problem
distinguishing between a character which is to be taken as a <
byte>, and interpreted as its corresponding <replacement string>,
one which is to be taken as its usual Telnet NVT value. In all
cases, however, s are to be interpreted immediately,
if their corresponding <replacement string>s had actually been
across the network. Expanded strings are not subject
reinterpretation, so that recursive definitions cannot be made
Telnet commands may be included in <replacement strings>; however
they must be totally contained within the macro or must begin
the macro and terminate outside of it. In particular, they may
begin outside a macro and continue or terminate inside one, since
macro replacement takes place while processing any Telnet command

Note that when skipping data due to Telnet SYNCH (INS/DM) processing
BM macro replacement should still take place, since (for example
"IAC DM" would be a valid <replacement string>.

The in the subcommand is intended to allow
receiver to allocate storage. IAC interpretation is not over-
during BM subcommands so that IAC SE will continue to
terminate malformed subcommands

The BM option is notably inefficient with regard to problems
definition and use of s as real data. It
expected that relatively few s will be defined and
they will represent relatively short strings. Since the Telnet
space between decimal 128 and decimal 254 is not normally used
except by implementations employing the original (obsolete)
protocol, it is recommended that s normally be drawn
that pool

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---