RFC 729

Telnet byte macro option

πŸ“… published May 1977, from ietf

TELNET Byte Macro Option πŸŽ€

  • Network Working Group 🌸
  • Author: Dave Crocker, Rand-ISD, (Dcrocker at Rand-Unix) πŸ’–
  • Date: 13 May 1977 πŸ“…
  • NIC: NlC: 40306 πŸ¦‹
  • Category/status: not stated in the document πŸ€·β€β™€οΈ
  • Obsoletes/Updates: no obsoletes or updates are listed ✨

1. Command name and code ✨

okay so the command is BM 19. that's the whole name and code, bestie πŸ’…

2. Command Meanings πŸ’–

IAC WILL BM

the sender of this command REQUESTS or AGREES to use the BM option. they'll send single data characters that are to be interpreted as if longer data strings had been sent. it's giving "I'll handle the shortcuts" πŸ¦‹

IAC WON'T BM

the sender of this option REFUSES to send single data characters that are to be interpreted as if longer data strings had been sent. so no shortcuts from this side, no cap πŸ™…β€β™€οΈ

IAC DO BM

the sender REQUESTS or AGREES to have the other side (the sender of WILL BM) issue single data characters that are to be interpreted as if longer data strings had been sent. it's the "please do the shortcuts for me" energy 🧚

IAC DON'T BM

the sender REFUSES to allow the other side to send single data characters that are to be interpreted as if longer data strings had been sent. this is the blanket "absolutely not" πŸ’€

IAC SB BM <DEFINE> <macro byte> <count>

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

here's the layout. the pieces mean:

  • <macro byte> is the data byte actually sent across the network. it may NOT be Telnet IAC (decimal 255). 🚫
  • <count> is a one-byte binary number. it says 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> gets 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 happens before any other Telnet interpretations, unless the <macro byte> is part of a BM subcommand. in that case, no special interpretation is to be made. main character energy πŸ‘‘

note that the effect of a particular <macro byte> can be negated by resetting it to "expand" into itself. reset arc unlocked πŸ”“

<DEFINE> is decimal 01. ✨

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

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

the receiver of the <DEFINE> for <macro byte> accepts the requested definition. from then on, they'll perform the indicated expansion whenever a <macro byte> is received and isn't part of a BM subcommand. yesss, deal accepted πŸ₯°

<ACCEPT> is decimal 02. πŸ’œ

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

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

the receiver of the <DEFINE> for <macro byte> refuses to perform the indicated translation from <macro byte> to <expansion string>. this happens either because the particular <macro byte> isn't an acceptable choice, or because the length of the <expansion string> exceeds available storage. the vibe is "not on my watch" πŸ™…β€β™€οΈ

<REFUSE> is decimal 03. πŸ“

<REASON> may be:

  • <BAD CHOICE>, which is decimal 01; or
  • <TOO LONG>, which is decimal 02. 🫢

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

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

the <macro byte> is treated as real data, not as a stand-in for the <expansion string>. it's just vibing as itself 🌈

<LITERAL> is decimal 03. 🧚

3. Default 🌸

the default is:

WON'T BM -- DON'T BM

so no reinterpretation of data is allowed by default. ngl, that's the safe baseline 🫢

4. Motivation for the option 🧚

okay, the why. right now, Telnet option subcommands need at least five characters sent over the network. that's IAC SB <Option name> IAC SE 😭

for subcommands that are used rarely, both in absolute numbers and compared to normal data, that overhead is tolerable. but sometimes it's NOT tolerable. like, data sent in blocks might need a "block separator" mark. if blocks are as small as five or ten bytes, then most of the cross-net data ends up being control info. the vibe is "the snacks are mostly wrapper" 🍬

the BM option is meant to be a simple data compression technique. its whole purpose is to remove that overhead from the communication channel. iconic, honestly πŸ‘‘

5. Description of the option πŸ’…

the option is enabled 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 multiple NOT characters. the receiver of data has no control over how mappings are defined and used, except for the ability to offer a blanket refusal. it's the sender's world, babe 🌍

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>. wait for the reply first, bestie ⏳

NOTE: The Telnet command character IAC (decimal 255) may be a member of an <expansion string>, but it is the ONLY character which may NOT be defined as a <macro byte>. ALL OTHER Telnet command characters use IAC as a preface, so they occupy a SEPARATE portion of the data space from regular data bytes. this is the one exception and it's SO important πŸ’€

RFC #729 Telnet Byte Macro Option Page 4

with the exception of IAC, data transferred as part of BM subcommands is NOT to be interpreted. it's only taken as its normal character values. this avoids the mix-up between a character that should be taken as a <macro byte> and expanded into its <expansion string>, and that same character being taken as its usual Telnet NVT value. πŸ™ˆ

in all other cases, though, <macro byte>s are interpreted immediately, as if the <expansion string> had actually been sent across the network. expanded strings are not subject to reinterpretation, so recursive definitions cannot be made. no infinite loops for us, thank you πŸ”

the <count> in the <DEFINE> subcommand lets the receiver allocate storage. IAC interpretation isn't overridden during BM subcommands, so IAC SE will still safely terminate malformed subcommands. to include IAC as part of a <DEFINE>, the string "IAC IAC" must be sent. double up, babe 🫢

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 represent relatively short strings. since the Telnet data space between decimal 128 and decimal 254 isn't normally used, except by implementations using the original Telnet protocol, it is recommended that <macro byte>s normally be drawn from that pool. the leftover space is giving "free real estate" 🏑✨

πŸ“¦ where this page comes from