Network Working Group
Request for Comments: 31
BINARY MESSAGE FORMS IN COMPUTER NETWORKS
Daniel Bobrow
Bolt, Beranek, and Newman
Cambridge, Massachusetts
William R. Sutherland
MIT Lincoln Laboratory
Lexington, Massachusetts
February 1968
[Page 1]
RFC 31 Binary Message Forms February 1968
MESSAGE FORMS IN COMPUTER NETWORKS
INTRODUCTION
Network communication between computers is becoming increasingly
important. However, the variety of installations working in the
areaprobably precludes standardization of the content and form
ofinter-computer messages. There is some hope, however, that a
standardway of defining and describing message forms can be developed
and usedto facilitate communication between computers. Just as ALGOL
serves asa standard vehicle for describing numerous algorithms, and
BNF servesas a standard for describing language syntax, a message
descriptionlanguage would be useful as a standard vehicle for
defining messageformats.
Considerable progress has been made at the low level of message
handling protocol and one can expect the ASCII protocols to be used.
Thediscussion which follows assumes that the mechanics of
exchangingmessages, check sums, repeat requestes, etc., have been
worked out. Thetopic of concern is how to describe the content and
intent of a binarymessage body when the network header and trailer
details have beenstripped off.
Most attempts at describing the content of binary messages
jump immediately into a consideration of the bit codings to be used.
Long,thin rectangles are drawn to represent the binary bit stream;
thisstream is sliced up into boxes, and tables generally describe the
bitoptions for each box. A better approach would be to provide a
symbolicBobrow & Sutherland Historical [Page 1]RFC 31 Binary Message
Forms in Computer Networks February 1968method for describing
messages. The symbolism, by avoiding immediatereferences to specific
bit details, should help one's understanding ofthe message content
and the alternatives available in the message body.When the basic
form of the binary message body is clear, the codingdetails of the
actual bit fields can be shown.
[Page 2]
RFC 31 Binary Message Forms February 1968
Describing a binary message body is not much different from
describing a text body or language. Text assumes fixed bit fields
each containingone character. Standard language description methods
(BNF) then showhow the characters can be concatenated and what
interpretation should beplaced on character groups. Binary message
descriptions require theadditional capacity of defining various size
fields in the message andthe interpretation to be placed on the bits
contained in the field.
A message description is initially intended as a reference standard
to be written down on paper and made available to new users of a
computernetwork. From this standard, the new user can discovr the
kind and formof the binary data being exchanged over the network.
Once this isknown, the programs necessary for using the network
facilities can becreated. Later on, in an established network, one
can envision thepromulgation of standards for newly developed binary
formats via theexchange of ASCII text messages over the network
itself instead of onpaper through the mail. Still farther into the
future, the text of abinary format standard could be used as input to
compiler-like programswhich automatically create data translation
programs for converting onebinary format to another. Right now,
though, some kind of binary datadescription method, however trivial,
is desperately needed.
[Page 3]
RFC 31 Binary Message Forms February 1968
A SUGGESTED BINARY FORMAT DESCRIPTION METHOD
The basic component of a binary message is a simple field
consisting of a consecutive number of bits in the message. Binary
messages consist ofconcatenated fields. A format description for a
binary message willconsist 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.
The following is a complete example of a binary message description
fora 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 messge
Field Equivalents:
PHDR <- '2' OPT
LHDR <- '4' OPT
GRPHDR <- '1' OPT
GRPEND <- '3' OPT
[Page 4]
RFC 31 Binary Message Forms February 1968
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
The declaration of a simple field includes a symbolic
name, and for lack of a better way, an English description of what
the contents of thefield 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 represented by a number in
single quotes followed by the field name. A number consists of
standard digitsconstrued as binary if zeros and ones. Other numbers
must be followedby a base indicator unless no confusion is possible;
Q is octal, D isdecimal.Bobrow & Sutherland Historical [Page 3]RFC 31
Binary Message Forms in Computer Networks February 1968
Example:
'1001' F1
'300D' COORD
'27Q' EXP
Field values are integer numbers assigned such that the
leastsignificant bit is sent first. Only that part of the number
which fitsthe field is used. Appropriate sign extension is needed
for negativenumbers and for numbers whose bit representation is
smaller than thefield.5.
[Page 5]
RFC 31 Binary Message Forms February 1968
Simple Field Equivalents
The declaration of a Simple Field Equivalent provides a symbolic
name which represents 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 (message or
message part) by indicating how other fields can be combined and is
similar to adefinition statement in BNF. The left side is a complex
field nameseparated (by <-) from the concatenation indications on the
right. Field names or equivalent names are concatenated by plus
(+),alternatives indicated by slash (/). Slash has precedence over
plus sothat A + B/C means A followd by either B or C. Alternatives
must bedistinguishable in their own right.
Characterization statement parts can be grouped in the normal
manner by parentheses. (A + B)/C means either A followed by B or
C.7.
Repetition Indicators
Repeated occurrences of a field may 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 interpretable as integrers can be assigned to a
variable within the right side of a characterization statement. This
variablecan then be used as a repetition indicator. Example:Bobrow &
Sutherland Historical [Page 4]RFC 31 Binary Message Forms in Computer
Networks February 1968
MS <- N1: EXP + CPAIR = N1
indicates that MS consists of field EXP interpreted as an integer
andthen exactly that number of CPAIRS. All variables are global in
scope.
Conditional Fields
Within a characterization statement a field may or may not
occur depending on the contents of some other previous field. This
situationis indicated by assigning a label to the determining field.
The conditional occurrence is then indicated by enclosing a condition
expression and the optional field description in brackets ([ and ]).
For example:
[Page 6]
RFC 31 Binary Message Forms February 1968
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.10.
Conditional Alternatives
Alternatives selected by the contents of some previous field rather
than by the contents of the alternative field itself are indicated by
anextension of the conditional field notation. For example:
SM := W : F1 + CPAIR + [W = C1 > CPAIR / C2 > PPAIRS /
The determining field occurs at the beginning of the
conditionalalternative and each alternative then includes its value
for thedetermining field and the alternative field then present.11.
Size of Simple Fields
A separate field size declaration is provided.
Simple Field Sizes:
F1 4
EXP 7
COORD 12
This size declaration should appear at the end of the
messagedescription; thus, forcing the reader to postpone an early
considerationof bit details. 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 ]
[Page 7]
