From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc31.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc31.txt (limited to 'doc/rfc/rfc31.txt') diff --git a/doc/rfc/rfc31.txt b/doc/rfc/rfc31.txt new file mode 100644 index 0000000..91c568c --- /dev/null +++ b/doc/rfc/rfc31.txt @@ -0,0 +1,395 @@ + + + + + + +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 <- '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 the field 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 digits construed as binary if zeros and ones. Other numbers + must be followed by a base indicator unless no confusion is possible; + Q is octal, D is decimal. + + Example: + '1001' F1 + '300D' COORD + '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. + + + + + + + + + + + [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 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 are concatenated by plus + (+), alternatives indicated by slash (/). Slash has precedence over + plus so that A + B/C means A followed by either B or C. Alternatives + must be distinguishable 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. + +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 integers can be assigned to a + variable within the right side of a characterization statement. This + variable can then be used as a repetition indicator. Example: + + 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. + +Conditional Fields + Within a characterization statement a field may or may not + occur depending on the contents of some other previous field. This + situation is 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. + +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] + -- cgit v1.2.3