RFC 31

RFC 31: BINARY MESSAGE FORMS IN COMPUTER NETWORKS ✨

Network Working Group 🎀 Request for Comments: 31 Title: BINARY MESSAGE FORMS IN COMPUTER NETWORKS (also headed MESSAGE FORMS IN COMPUTER NETWORKS) 💜 Authors: Daniel Bobrow (Bolt, Beranek, and Newman, Cambridge, Massachusetts) and William R. Sutherland (MIT Lincoln Laboratory, Lexington, Massachusetts) 👑 Date: February 1968 📅 Category, obsoletes, updates: this doc doesn't list any of these, so there's nothing to report 🙈

---

INTRODUCTION 🦋

okay so network communication between computers is getting SO important 😭 but the sheer variety of installations out there probably means nobody's going to standardize the content and form of intercomputer messages. still, there's hope! a standard way of defining and describing message forms could totally help computers talk to each other 🫶

think about it like this: ALGOL is the standard vehicle for describing tons of algorithms, and BNF is the standard for describing language syntax. a message description language would be that same kind of standard, but for message formats. iconic energy 💅

low-level message handling protocols have come a long way, and you can expect the ASCII protocols to be used ✨ this doc assumes the mechanics of exchanging messages (check sums, repeat requests, etc.) are already sorted. the actual question is how to describe the content and intent of a binary message body once the network header and trailer details have been stripped off 🔥

most attempts at describing binary message content jump straight into bit codings 😩 long, thin rectangles get drawn to represent the bit stream, the stream gets sliced into boxes, and tables describe the bit options for each box. ngl that's a lot. a better approach is a symbolic method for describing messages 🌸 the symbolism avoids immediate references to specific bit details, so it's easier to understand what the message contains and what alternatives it allows. once the basic form of the binary message body is clear, the coding details of the actual bit fields can be shown 🍓

describing a binary message body isn't that different from describing a text body or language 💖 text assumes fixed bit fields, each holding one character. standard language description methods (BNF) then show how characters can be concatenated and what interpretation goes on character groups. binary descriptions need extra stuff on top: defining fields of various sizes and the interpretation to be placed on the bits inside each field ✨

a message description is first meant to be a reference standard written on paper and handed to new users of a computer network. from it, a new user can figure out the kind and form of binary data being exchanged over the network. once that's known, the programs needed to use the network facilities can be created 🧚 later, in an established network, standards for newly developed binary formats could be shared by exchanging ASCII text messages over the network itself instead of mailing paper around 💌 even further in the future, the text of a binary format standard could be fed into compiler-like programs that automatically create data translation programs for converting one binary format to another 🤯 but for now, some kind of binary data description method, however trivial, is desperately needed 😭🫶

A SUGGESTED BINARY FORMAT DESCRIPTION METHOD 🌈

the basic component of a binary message is a simple field, which is a consecutive run of bits in the message. binary messages are just concatenated fields 🎀 a format description for a binary message consists of a title and four declarative sections:

1) Symbolic names are declared for all the different kinds of
   fields found in the binary format being defined.
2) Symbolic names are declared for commonly used values of
   particular fields.
3) The legal ways of concatenating fields are indicated.
4) The number of bits in each field and any special considerations
   of bit codings are declared.

here's a complete example of a binary message description for a trivial kind of pictorial data 🦋

Title: Illustrative graphic data format for a hierarchally
   structured picture of lines and points.
Simple Fields:
   OPT   - Option Control Field
   COORD - Numerical Coordinate Value
   ID    - Identnumber for group of picture parts
   COUNT - Number of units in message


Field Equivalents:
   PHDR   <- '2' OPT
   LHDR   <- '4' OPT
   GRPHDR <- '1' OPT
   GRPEND <- '3' OPT

Characterizations:
   CPAIR   <- COORD = 2
   POINT   <- PHDR + CPAIR
   LINE    <- LHDR + CPAIR = 2
   PARTS   <- POINT/LINE/PARTS + PARTS
   PIXUNIT <- GRPHDR + ID + PARTS + GRPEND
   PIXMSG  <- '5' OPT + N: COUNT + PIXUNIT = N + '0' OPT
Simple Field Sizes:
   OPT   3
   COORD 14
   ID    9
   COUNT 6

Declaration of Simple Fields 💅

declaring a simple field means giving it a symbolic name, plus (for lack of a better way) an English description of what its contents represent ✨ for example:

Simple Fields:
   F1    - Geometric Options
   EXP   - STD Number - Exponent
   COORD - STD Number - Geometric Coordinates

Representing Field Values 🔢

a field with a specific value can be written as a number in single quotes followed by the field name ✨ a number is made of standard digits, read as binary if they're just zeros and ones. other numbers need a base indicator unless no confusion is possible: Q is octal, D is decimal 🧠

'1001' F1
'300D' COORD
'27Q'   EXP

field values are integer numbers, assigned so that the least significant bit is sent first 🫶 only the part of the number that fits in the field is used. negative numbers, and numbers whose bit representation is smaller than the field, need appropriate sign extension 🌸

Simple Field Equivalents 💖

a Simple Field Equivalent gives a symbolic name to a particular field with a specific value ✨ example:

Field Equivalents:
   C1 <- '1001' F1
   C2 <- '1010' F1

Characterization Statement 🦋

a characterization statement defines a complex field (a message or message part) by saying how other fields can be combined 💅 it's similar to a definition statement in BNF. the left side is a complex field name, separated by <- from the concatenation indications on the right. field names (or equivalent names) get joined with plus (+), and alternatives are marked with slash (/) 🔥

slash has precedence over plus, so A + B/C means A followed by either B or C. alternatives have to be distinguishable in their own right 👑

parts of a characterization statement can be grouped with parentheses, like normal. (A + B)/C means either A followed by B, or C 🎀

Repetition Indicators 🔁

repeated occurrences of a field can be indicated by following the field name with an equal sign (=) and a number ✨ for example:

CPAIR  <- (COORD = 2) i.e. exactly two COORD fields
PPAIRS <- (C1 + CPAIR = 10D) / (C2 + CPAIR = 40D)

Assignments Within a Characterization Statement 🧚

simple fields that can be read as integers can be assigned to a variable on the right side of a characterization statement 💌 that variable can then be used as a repetition indicator. example:

MS <- N1: EXP + CPAIR = N1

this means MS is field EXP read as an integer, followed by exactly that many CPAIRs 🌈 all variables are global in scope 🫶

Conditional Fields 🌸

inside a characterization statement, a field may or may not occur depending on the contents of some other earlier field 🤔 this is marked by giving a label to the determining field. the conditional occurrence is then shown by putting a condition expression and the optional field description in brackets ([ and ]) 💖 for example:

SS <- V:F1 + CPAIR + [V = C1 > PPAIRS]

which defines a format of 2 and perhaps 3 fields: a) Field F1 labeled V, followed by b) Field CPAIR, followed by c) Field PPAIRS if the first field (V) was C1; otherwise, this third field is not present in the message.

Conditional Alternatives ✨

alternatives picked by the contents of some previous field (rather than by the alternative field's own contents) are shown with an extension of the conditional field notation 🦋 for example:

SM := W : F1 + CPAIR + [W = C1 > CPAIR / C2 > PPAIRS /

the determining field sits at the beginning of the conditional alternative, and each alternative includes its value for the determining field, plus the alternative field that's then present 🔥

Size of Simple Fields 📏

there's a separate field size declaration for this 💅

Simple Field Sizes:
      F1    4
      EXP   7
      COORD 12

this size declaration should appear at the end of the message description 🙈 that forces the reader to put off thinking about bit details until later 😌 xmodmap -e "add lock = Caps_Lock"

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Dave Bachmann 1/98 ] 🎀💜🫶