Network Working Group Request for Comments: 31
Bolt, Beranek, and Newman
William R. Sutherland
MIT Lincoln Laboratory
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
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.
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.
OPT - Option Control Field COORD - Numerical Coordinate Value ID - Identnumber for group of picture parts COUNT - Number of units in message
PHDR <- '2' OPT LHDR <- '4' OPT GRPHDR <- '1' OPT GRPEND <- '3' OPT
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
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 the field represent. For example:
F1 - Geometric Options EXP - STD Number - Exponent COORD - STD Number - Geometric Coordinates
'27Q' EXP Field values are integer numbers assigned such that the least significant bit is sent first. Only that part of the number which fits the field is used. Appropriate sign extension is needed for negative numbers and for numbers whose bit representation is smaller than the field.
MS <- N1: EXP + CPAIR = N1
indicates that MS consists of field EXP interpreted as an integer and then exactly that number of CPAIRS. All variables are global in scope.
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.
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 ]