GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc31

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]
/data/webs/external/dokuwiki/data/pages/rfc/rfc31.txt · Last modified: 1998/06/10 22:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki