File: rfc31.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 10,925 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
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]