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

---

Network Working Group Dave Crocker, Rand-
Request for Comments: 729 (Dcrocker at Rand-Unix
NlC: 40306 13 May l977




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 sing1e data characters which are to
interpreted as if longer data strings had been sent

IAC WON'T

The sender of this option REFUSES to send single
characters which are to be interpreted as if longer
strings had been sent

IAC DO

The sender REQUESTS or AGREES to have the other side (send
WILL BM) issue send single data characters which are to
interpreted as if longer 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 longer
strings had been sent

IAC SB BM <expansion string> IAC
where

is the data byte actually to be sent
the network; it may NOT be Telnet IAC (decimal 255).


RFC #729 Telnet Byte Macro Option Page 2



is a one-byte binary number, indicating how
<expansion string> characters follow, up to the ending
SE, but not including it

<expansion string> is a string of one or more Telnet
characters and/or commands, which the is
represent; any character may occur within an <
string>.

The indicated will be sent instead of
indicated <expansion string>. The receiver of the (the sender of the DO BM) is to behave EXACTLY as if
<expansion string> of bytes had instead been received from
network. This interpretation is to occur before any
Telnet interpretations, unless the occurs as
of a BM subcommand; in this case no special interpretation
to be made

Note that the effect of a particular may
negated by reseting it to "expand" into itself

is decimal 01.


IAC SB BM IAC

The receiver of the for accepts
requested definition and will perform the indicating
whenever a is received and is not part of a
subcommand

is decimal 02.


IAC SB BM IAC

The receive of the for refuses
perform the indicated translation from
<expansion string> either because the particular is not an acceptable choice or because the length of
<expansion string> exceeds available storage

is decimal 03.

may

which is decimal 01;

which is decimal 02.


RFC #729 Telnet Byte Macro Option Page 3




IAC SB BM IAC

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

is decimal 03.




3. Default

WON'T BM -- DON'T

No reinterpretation of data is allowed

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 sub-commands which are employed infrequently,
absolute numbers and in relation to normal data, this overhead
tolerable. In other cases, however, it is not. For example,
which is sent in a block-oriented fashion may need a "
separator" mark. If blocks are commonly as small as five or
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

The option is enabled through the standard Telnet
negotiation process. Afterwards, the SENDER of data (the side
sends the IAC WILL BM) is free to define and use mappings
single and multiple NOT characters. Except for the ability to
a blanket refusal, the receiver of data has no control over
definition and use of mappings

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

NOTE: The Telnet command character IAC (decimal 255) may be
member of an <expansion string> but is the ONLY character which
NOT be defined as a . ALL OTHER Telnet
characters use IAC as a preface and therefore occupy a
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
subcommands are NOT to be interpreted. They are to be taken only
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 <expansion string>,
that same character to be taken as its usual Telnet NVT value.
all other cases, however, s are to be
immediately, as if the <expansion string> had actually been
across the network. Expanded strings are not subject
reinterpretation, so that recursive definitions cannot be made

The in the subcommand allows the receiver
allocate storage. IAC interpretation is not over-ridden during
subcommands so that IAC SE will continue to safely
malformed subcommands. To include IAC as part of a ,
string "IAC IAC" must be sent

The BM option is notably inefficient with regard to problems
definition and use of s as real data.
is expected that relatively few s will be defined
that they will represent relatively short strings. Since the
data space between decimal 128 and decimal 254 is not
used, except by implementations employing the original
protocol, it is recommended that s normally be
from 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

---