RFC 735

Revised Telnet byte macro option

๐Ÿ“… published November 1977, from ietf

okay bestie, RFC 735 is here and it is a MASTERPIECE ๐ŸŽ€๐Ÿ’…

This one is from the Network Working Group and it's the Revised TELNET Byte Macro Option, the "Telnet Byte Macro Option" on the header ๐Ÿฆ‹. It was written by David H. Crocker (Rand-ISD, NIC #42083, reachable as Dcrocker at Rand-Unix) and Richard H. Gumpertz (Carnegie-Mellon University, Gumpertz at CMU-10A). The date is 3 November 1977 ๐Ÿ“…. It obsoletes RFC #729 (NIC #40306) ๐Ÿ’€, so RFC 729 is the old version and this is the glow-up ๐Ÿ‘‘.


1. Command name and code โœจ

The command is BM 19, so the name is BM and the code is 19. ๐Ÿงš

2. Command Meanings ๐Ÿ’–

Okay so this section is the heart of the whole thing, so let's go through the commands one by one ๐ŸŒธ

IAC WILL BM

The sender of this command REQUESTS or AGREES to use the BM option, and it will send single data characters that are supposed to be read as if whole replacement data strings had been sent. Main character energy ๐Ÿ’…

IAC WON'T BM

The sender of this option REFUSES to send single data characters that are supposed to be read as if whole replacement data strings had been sent. Any existing BM <macro byte> definitions get discarded, meaning they're reset back to their original data meanings ๐Ÿงน

IAC DO BM

The sender REQUESTS or AGREES to have the other side (the sender of WILL BM) send single data characters that are supposed to be read as if whole replacement data strings had been sent. โœจ

IAC DON'T BM

The sender REFUSES to let the other side send single data characters that are supposed to be read as if whole replacement data strings had been sent. Any existing BM <macro byte> definitions are to be discarded. ๐Ÿ™ˆ

IAC SB BM <DEFINE> <macro byte> <count> <replacement string> IAC SE

Here's the layout, verbatim:

IAC SB BM <DEFINE> <macro byte> <count>
                                          <replacement string> IAC SE

Where:

  • <macro byte> is the data byte that actually gets sent across the network. It may NOT be Telnet IAC (decimal 255), but it can be any other 8-bit character ๐Ÿ“
  • <count> is one 8-bit byte binary number, saying how many <replacement string> characters follow, up to the ending IAC SE but not including it. Doubled IACs in the definition only count as one character per pair, so keep that in mind ๐Ÿงฎ
  • <replacement string> is a string of zero or more Telnet ASCII characters and/or commands that the <macro byte> is supposed to stand for. Any character can show up in a <replacement string>. BUT an IAC in the string must be doubled so it gets read later as an IAC. To be read later as data byte 255, it has to be quadrupled in the original <replacement string> spec. Ngl this part is a lot ๐Ÿ’€

So the indicated <macro byte> gets sent instead of the indicated <replacement string>. The receiver of the <macro byte> (the sender of DO BM) is supposed to behave EXACTLY as if that <replacement string> of bytes had actually been received from the network. This interpretation happens before any other Telnet interpretations, unless the <macro byte> is part of a Telnet command. In that case, no special interpretation happens. Specifically, an entire Telnet subnegotiation (from IAC SB through IAC SE) counts as a Telnet command where NO replacement should be done ๐Ÿšซ

The effect of a particular <macro byte> can be negated by resetting it so it "expands" into itself ๐Ÿ”„

IAC SB BM <DEFINE> X <0> IAC SE can be used to make X get ignored in the data stream. ๐Ÿซฅ

<DEFINE> is decimal 1. 1๏ธโƒฃ

IAC SB BM <ACCEPT> <macro byte> IAC SE

The receiver of the <DEFINE> for <macro byte> accepts the requested definition, and it will do the indicated replacement whenever a <macro byte> gets received that isn't part of any IAC Telnet command sequence. โœ…

<ACCEPT> is decimal 2. 2๏ธโƒฃ

IAC SB BM <REFUSE> <macro byte> <REASON> IAC SE

The receiver of the <DEFINE> for <macro byte> REFUSES to do the indicated translation from <macro byte> to <replacement string>. Reasons it might do that: the particular <macro byte> is not an acceptable choice, the length of the <replacement string> is more than the available storage, the length of the actual <replacement string> didn't match the length predicted in the <count>, or some unspecified reason ๐Ÿ™…โ€โ™€๏ธ

<REFUSE> is decimal 3. 3๏ธโƒฃ

<REASON> can be:

  • <BAD-CHOICE> which is decimal 1;
  • <TOO-LONG> (for receiver's storage) which is decimal 2;
  • <WRONG-LENGTH> (of actual string compared with promised length in <count>) which is decimal 3; or
  • <OTHER-REASON> (intended for use only until this document can be updated to include reasons the authors didn't anticipate) which is decimal zero (0). ๐Ÿคทโ€โ™€๏ธ

IAC SB BM <LITERAL> <macro byte> IAC SE

The <macro byte> is to be treated as real data, rather than as standing in for the <replacement string> ๐Ÿฆ‹

Note that this subcommand can't be used during Telnet subcommands. Subcommands are defined to end with the next occurrence of "IAC SE", so putting this BM subcommand inside any Telnet subcommand would cut the containing subcommand off early ๐Ÿ˜ญ

<LITERAL> is decimal 4. 4๏ธโƒฃ

IAC SB BM <PLEASE CANCEL> <macro byte> <REASON> IAC SE

The RECEIVER of the defined <macro byte> (that's the sender of IAC DO BM) asks the sender of the <macro byte> to cancel its definition. <REASON> is the same as for the <REFUSE> subcommand. ๐Ÿ™

The <macro byte> sender should (but is not required to) respond by resetting the <macro byte>, which means sending IAC SB BM <DEFINE> <macro byte> <1> <macro byte> IAC SE. ๐Ÿ”

If the receiver absolutely insists on cancelling a given macro, the best it can do is turn off the entire option with IAC DONT BM, wait for an acknowledging IAC WONT BM, and then restart the option with IAC DO BM. This resets all the other macroes as well, but it lets the receiver REFUSE with code BAD CHOICE if/when the foreign site tries to redefine the macro in question. It's a whole reset situation, bestie ๐Ÿฅฒ

3. Default ๐ŸŒˆ

The default is WON'T BM -- DON'T BM, meaning no reinterpretation of data bytes is done. Boring but important ๐Ÿซถ

4. Motivation for the option ๐Ÿ“

Right now, subcommands for Telnet options need at least five characters to be sent over the network (that's IAC SB <Option name> IAC SE). For subcommands that get used infrequently, both in absolute numbers and compared to normal data, that overhead is fine. In other cases, though, it's not ๐Ÿ˜ค For example, data sent in a block-oriented way might need a "block separator" mark. If blocks are commonly as small as five or ten bytes, then most of the cross-net data is going to be control information. The BM option is meant to be a simple data compression technique that removes this overhead from the communication channel. Efficiency era ๐Ÿง โœจ

5. Description of the option ๐Ÿ”ฅ

The option gets turned on through the standard Telnet Option negotiation process. After that, the SENDER of data (the side that sends the IAC WILL BM) is free to define and use mappings between single and replacement NVT characters. Except for the ability to refuse particular definitions, the receiver of data has no control over how mappings get defined and used. ๐Ÿ‘‘

The sender (of the WILL BM) is prohibited from using or redefining a <macro byte> until it has received an <ACCEPT>, a <REFUSE>, or DONT BM in reply to a <DEFINE>. โณ

NOTE: The Telnet command character IAC (decimal 255) may be a member of a <replacement string>, but it is the ONLY character which may NOT be defined as a <macro byte>. ๐Ÿšจ

Within any Telnet command (any sequence beginning with IAC), macro replacement may NOT take place. Data are only to be interpreted as their normal character values. This avoids the problem of telling apart a character that's supposed to be taken as a <macro byte> and interpreted as its <replacement string>, from one that's supposed to be taken as its usual Telnet NVT value. In all other cases, <macro byte>s are to be interpreted immediately, as if their <replacement string>s had actually been sent across the network. Expanded strings are not subject to reinterpretation, so recursive definitions can't be made ๐Ÿ”๐Ÿšซ Telnet commands may be included in <replacement string>s. However, they must be totally contained within the macro, or they must begin within the macro and end outside of it. In particular, they may NOT begin outside a macro and continue or end inside one, since no macro replacement happens while processing any Telnet command. ๐Ÿงฉ

Note that when skipping data because of Telnet SYNCH (INS/DM) processing, BM macro replacement should still take place, since (for example) IAC DM would be a valid <replacement string>. ๐Ÿซง

The <count> in the <DEFINE> subcommand is meant to let the receiver allocate storage. IAC interpretation is not overridden during BM subcommands, so IAC SE will keep safely ending malformed subcommands. ๐Ÿ›Ÿ

The BM option is notably inefficient when it comes to problems during <macro byte> definition and using <macro byte>s as real data. It's expected that relatively few <macro byte>s will be defined and that they'll stand for relatively short strings. Since the Telnet data space between decimal 128 and decimal 254 isn't normally used, except by implementations using the original (obsolete) Telnet protocol, it is recommended that <macro byte>s normally be drawn from that pool. ๐ŸŒธ๐Ÿ’œ

๐Ÿ“ฆ where this page comes from