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 area
probably precludes standardization of the content and form of inter-
computer messages. There is some hope, however, that a standard way
of defining and describing message forms can be developed and used to
facilitate communication between computers. Just as ALGOL serves as
a standard vehicle for describing numerous algorithms, and BNF serves
as a standard for describing language syntax, a message description
language would be useful as a standard vehicle for defining message
formats.
Considerable progress has been made at the low level of message
handling protocol and one can expect the ASCII protocols to be used.
The discussion which follows assumes that the mechanics of exchanging
messages, check sums, repeat requests, etc., have been worked out.
The topic of concern is how to describe the content and intent of a
binary message body when the network header and trailer details have
been stripped 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;
this stream is sliced up into boxes, and tables generally describe
the bit options for each box. A better approach would be to provide
a symbolic method for describing messages. The symbolism, by
avoiding immediate references to specific bit details, should help
one's understanding of the message content and the alternatives
available in the message body. When the basic form of the binary
message body is clear, the coding details 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 containing one character. Standard language description methods
(BNF) then show how the characters can be concatenated and what
interpretation should be placed on character groups. Binary message
descriptions require the additional capacity of defining various size
fields in the message and the 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
computer network. From this standard, the new user can discover the
kind and form of the binary data being exchanged over the network.
Once this is known, the programs necessary for using the network
facilities can be created. Later on, in an established network, one
can envision the promulgation of standards for newly developed binary
formats via the exchange of ASCII text messages over the network
itself instead of on paper through the mail. Still farther into the
future, the text of a binary format standard could be used as input
to compiler-like programs which automatically create data translation
programs for converting one binary format to another. Right now,
though, some kind of binary data description 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 of concatenated fields. A format description for a
binary message will consist 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
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
RFC 31 Binary Message Forms February 1968
Characterizations:
CPAIR
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
RFC 31 Binary Message Forms February 1968
SS 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 selected by the contents of some previous field rather
than by the contents of the alternative field itself are indicated by
an extension 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 conditional
alternative and each alternative then includes its value for the
determining field and the alternative field then present.
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
message description; thus, forcing the reader to postpone an early
consideration of 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]