File: rfc138.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 (1291 lines) | stat: -rw-r--r-- 46,641 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
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291






Network Working Group                                       Bob Anderson
Request for Comments: 138                                           Rand
NIC 6715                                                       Vint Cerf
                                                                    UCLA
                                                            Eric Harslem
                                                            John Heafner
                                                                    Rand
                                                              Jim Madden
                                                          U. of Illinois
                                                            Bob Metcalfe
                                                                     MIT
                                                           Arie Shoshani
                                                                     SDC
                                                               Jim White
                                                                    UCSB
                                                              David Wood
                                                                   Mitre
                                                           28 April 1971

         STATUS REPORT ON PROPOSED DATA RECONFIGURATION SERVICE

                                 CONTENTS
     I.  INTRODUCTION .................................    2

         Purpose of this RFC ..........................    2
         Motivation ...................................    2

    II.  OVERVIEW OF DATA RECONFIGURATION SERVICE .....    3

         Elements of Data Reconfiguration Service .....    3
         Conceptual Network Connections ...............    3
         Connection Protocols and Message Formats .....    4
         Example Connection Configurations ............    6

   III.  THE FORM MACHINE .............................    7

         Input/Output Stream and Forms ................    7
         Form Machine BNF Syntax ......................    7
         Alternate Specification of Form Machine Syntax    8
         Forms ........................................    9
         Rules ........................................   10
         Terms ........................................   10

           Term Format 1 ..............................   11
           Term Format 2 ..............................   11
           Term Format 3 ..............................   13
           Term Format 4 ..............................   13
           Application of a Term ......................   14



Anderson, et al.                                                [Page 1]

RFC 138               Data Reconfiguration Service          April 1971


           Restrictions and Interpretations of
             Term Functions ...........................   14
         Term and Rule Sequencing .....................   16

    IV.  EXAMPLES .....................................   16

         Remarks ......................................   16
         Field Insertion ..............................   17
         Deletion .....................................   17
         Variable Length Records ......................   17
         String Length Computation ....................   18
         Transposition ................................   18
         Character Packing and Unpacking ..............   18

     V.  PROPOSED USES OF DATA RECONFIGURATION SERVICE    19

    VI.  IMPLEMENTATION PLANS .........................   20

   Appendix A .........................................   21

         Note 1 to the DRS Working Group ..............   21
         Note 2 to the DRS Working Group ..............   22

I.  INTRODUCTION

   PURPOSE OF THIS RFC

   The purpose of this RFC is to describe, in part, a proposed Network
   experiment and to solicit comments on any aspect of the experiment.
   The experiment involves a software mechanism to reformat Network data
   streams.  The mechanism can be adapted to numerous Network
   application programs.  We hope that the results of the experiment
   will lead to a further standard service that embodies the principles
   described in this RFC.   We would like comments on the
   appropriateness of this work as a Network experiment and also
   comments on particular Network data reformatting needs that could not
   easily be accomplished using these techniques.

MOTIVATION

   Application programs require specific data I/O formats yet the
   formats are different from program to program.  We take the position
   that the Network should adapt to the individual program requirements
   rather than changing each program to comply with a standard.  This
   position doesn't preclude the use of standards that describe the
   formats of regular message contents; it is merely an interpretation
   of a standard as being a desirable mode of operation but not a
   necessary one.



Anderson, et al.                                                [Page 2]

RFC 138               Data Reconfiguration Service          April 1971


   In addition to differing program requirements, a format mismatch
   problem occurs where users wish to employ many different kinds of
   consoles to attach to a single service program.  It is desirable to
   have the Network adapt to individual console configurations rather
   than requiring unique software packages for each console
   transformation.

   One approach to providing adaptation is for those sites with
   substantial computing power to offer a data reconfiguration service;
   a proposed example of such a service is described here.

   The envisioned modus operandi of the service is that an applications
   programmer defines _forms_ that describe data reconfigurations.  The
   service stores the forms by name.  At a later time, a user (perhaps a
   non-programmer) employs the service to accomplish a particular
   transformation of a Network data stream, simply by calling the form
   by name.

   We have attempted to provide a notation tailored to some specifically
   needed instances of data reformatting while keeping the notation and
   its underlying implementation within some utility range that is
   bounded on the lower end by a notation expressive enough to make the
   experimental service useful, and that is bounded on the upper end by
   a notation short of a general purpose programming language.


II.  OVERVIEW OF THE DATA RECONFIGURATION SERVICE

ELEMENTS OF THE DATA RECONFIGURATION SERVICE

   An implementation of the Data Reconfiguration Service (DRS) includes
   modules for connection protocols, a handler of some requests that can
   be made of the service, a compiler and/or interpreter (called the
   Form Machine) to act on those requests, and a file storage module for
   saving and retrieving definitions of data reconfigurations (forms).
   This section highlights connection protocols and requests.  The next
   section covers the Form Machine language in some detail.  File
   storage is not described in this document because it is transparent
   to the use of the service and its implementation is different at each
   DRS host.

CONCEPTUAL NETWORK CONNECTIONS

   There are three conceptual Network connections to the DRS, see Fig.
   1.

         1)  The control connection (CC) is between an originating user
             and the DRS.  A form specifying data reconfiguration is



Anderson, et al.                                                [Page 3]

RFC 138               Data Reconfiguration Service          April 1971


             defined over this connection and is applied to data passing
             over the two connections described below.
         2)  The user connection (UC) is between a user process and the
             DRS.
         3)  The server connection (SC) is between the DRS and the
             serving process.

   Since the goal is to adapt the Network to user and server processes,
   a minimum of requirements are imposed on the UC and SC.


      +-------------+   CC   +-----------+   SC   +-----------+
      | ORIGINATING +--------+    DRS    +--------+ SERVER    |
      |    USER     |   ^    |           |    ^   | PROCESS   |
      +-------------+   |    +------+----+    |   +-----------+
                        |          /          |
                     Telnet       / <------ Simplex or Duplex
                    Protocol   UC/            Connections
                   Connection   /
                               /
                        +-----+-----+
                        | USER      |
                        | PROCESS   |
                        +-----------+

                Figure 1.  DRS Network Connections


CONNECTION PROTOCOLS AND MESSAGE FORMATS

   Over a control connection the dialog is directly between an
   originating user and the DRS.  Here the user is defining forms or
   assigning forms to connections for reformatting.

   The user connects to the DRS via the initial connection protocol
   (ICP) specified in NWG/RFC #80, version 1.  Rather than going through
   a logger, the user calls on a particular socket on which the DRS
   always listens.  DRS switches the user to another socket pair.

   Messages sent over a control connection are of the types and formats
   to be specified for TELNET.  Thus, a user at a terminal should be
   able to connect to a DRS via his local TELNET, for example, as shown
   in Fig.  2.








Anderson, et al.                                                [Page 4]

RFC 138               Data Reconfiguration Service          April 1971


                                          +--------------+
                         +--------+  CC   |              |
                 +-------+ TELNET +-------+     DRS      |
                 |       +--------+       |              |
                 |                        +--------------+
      +----------+---------+
      |      USER          |
      |(TERMINAL OR PROGRAM|
      +--------------------+

           Figure 2.  A TELNET Connection to DRS

   When a user connects to DRS he supplies a six-character user ID (UID)
   as a qualifier to guarantee the uniqueness of his form names.  He
   will have (at least) the following commands:

         1.  DEFFORM (name)
         2.  ENDFORM (name)

             These two commands define a form, the text of which is
             chronologically entered between them.  The (name) is six
             characters.  The form is stored in the DRS local file
             system.

         3.  PURGE (name)

             The named form, as qualified by the current UID, is purged
             from the DRS file system.

         4.  LISTNAMES (UID)

             The unqualified names of all forms assigned to UID are
             returned.

         5.  LISTFORM (name)

             The source text of a named form is returned.

         6.  DUPLEXCONNECT (user site, user send, user receive,
                        user method, server site, server
                        send, server receive, server method,
                        user-to-server form, server-to-user form)

         7.  SIMPLEXCONNECT (send site, send socket, send
                          method, receive site, receive
                          socket, receive method, form)





Anderson, et al.                                                [Page 5]

RFC 138               Data Reconfiguration Service          April 1971


   Either one, both, or neither of the two parties specified in 6 or 7
   may be at the same host as the party issuing the request.  Sites and
   sockets specify user and server for the connection.  Method indicates
   the way in which the connection is established.  Three options are
   provided:
        1)  Site/socket already connected to DRS as a dummy
            control connection.  (A dummy control connection
            should not also be the real control connection.)
        2)  Connect via standard ICP. (Only for command no. 6.)
        3)  Connect directly via STR, RTS.

EXAMPLE CONNECTION CONFIGURATIONS

   There are basically two modes of DRS operation: 1) the user wishes to
   establish a DRS UC/SC connection(s) between two programs and 2) the
   user wants to establish the same connection(s) where he (his
   terminal) is at the end of the UC or the SC.  The latter case is
   appropriate when the user wishes to interact from his terminal with
   the serving process (e.g., a logger).

   In the first case (Fig. 1, where the originating user is either a
   terminal or a program) the user issues the appropriate CONNECT
   command.  The UC/SC can be simplex or duplex.

   The second case has two possible configurations, shown in Figs. 3 and
   4.

               +--------+  CC  +--------+      +------+
               |        +------+        |  SC  |      |
     +------+ /| TELNET |  UC  |  DRS   +------+  SP  |
     |      |/ |        +------+        |      |      |
     | USER | /+--------+      +--------+      +------+
     |      |/
     +------+

            Figure 3.  Use of Dummy Control Connection

               +--------+
     +------+ /|  USER  |  CC  +--------+      +------+
     |      |/ |  SIDE  +------+        |  SC  |      |
     | USER |  +--------+  UC  |  DRS   +------+  SP  |
     |      |\ | SERVING+------+        |      |      |
     +------+ \|  SIDE  |      +--------+      +------+
               +--------+

            Figure 4.  Use of Server TELNET





Anderson, et al.                                                [Page 6]

RFC 138               Data Reconfiguration Service          April 1971


   In Fig. 3 the user instructs his TELNET to make two duplex
   connections to DRS.  One is used for control information (the CC) and
   the other is a dummy.  When he issues the CONNECT he references the
   dummy duplex connection (UC) using the "already connected" option.

   In Fig. 4 the user has his TELNET (user side) call the DRS.  When he
   issues the CONNECT the DRS calls the TELNET (server side) which
   accepts the call on behalf of the console.  This distinction is known
   only to the user since to the DRS the configuration in Fig. 4 appears
   identical to that in Fig. 1.  Two points should be noted:

        1)  TELNET protocol is needed only to define forms and direct
            connections.  It is not required for the using and serving
            processes.
        2)  The using and serving processes need only a minimum of
            modification for Network use, i.e., an NCP interface.


III.  THE FORM MACHINE

INPUT/OUTPUT STREAMS AND FORMS

   This section describes the syntax and semantics of forms that specify
   the data reconfigurations.  The Form Machine gets an input stream,
   reformats the input stream according to a form describing the
   reconfiguration, and emits the reformatted data as an output stream.

   In reading this section it will be helpful to envision the
   application of a form to the data stream as depicted in Fig. 5.  An
   input stream pointer identifies the position of data (in the input
   stream) that is being analyzed at any given time by a part of the
   form.  Likewise, an output stream pointer locates data being emitted
   in the output stream.


       /\/\                                                  /\/\
  ^    |  |                     FORM                         |  |   ^
  |    |  |                -----------------                 |  |   |
  |    |  |            +-  -----------------  -+             |  |   |
  |    |  |            |   CURRENT PART OF     |             |  |   |
INPUT  |  |<= CURRENT <    -----------------    > CURRENT => |  | OUTPUT
STREAM |  |   POINTER  |   FORM BEING APPLIED  |  POINTER    |  | STREAM
       |  |            +-  -----------------  -+             |  |
       |  |                -----------------                 |  |
       |  |                -----------------                 |  |
       |  |                -----------------                 |  |
       \/\/                                                  \/\/
              Figure 5.  Application of Form to Data Streams



Anderson, et al.                                                [Page 7]

RFC 138               Data Reconfiguration Service          April 1971


FORM MACHINE BNF SYNTAX

   form           ::=  rule | rule form

   rule           ;;=  label  inputstream  outputstream ;

   label          ::=  INTEGER | <null>

   inputstream    ::=  terms | <null>

   terms          ::=  term | terms , term

   outputstream   ::=  : terms | <null>

   term           ::=  identifier | identifier  descriptor |
                       descriptor | comparator

   identifier     ::=  an alpha character followed by 0 to 3
                       alphamerics

   descriptor     ::=  (replicationexpression , datatype ,
                       valueexpression , lengthexpression  control)

   comparator     ::=  (value  connective  value  control)  |
                       (identifier .<=>. control)

   replicationexpression  ::=  arithmeticexpression | <null>

   datatype       ::=  B | O | X | E | A

   valueexpression  ::=  value | <null>

   lengthexpression  ::=  # | arithmeticexpression | <null>

   connective     ::=  .LE. | .LT. | .GE. | .GT. | .EQ. | .NE.

   value          ::=  literal | arithmeticexpression

   arithmeticexpression  ::=  primary | primary operator
                              arithmeticexpression

   primary        ::=  identifier | L(identifier) | V(identifier) |
                       INTEGER

   operator       ::=  + | - | * | /

   literal        ::=  literaltype "string"




Anderson, et al.                                                [Page 8]

RFC 138               Data Reconfiguration Service          April 1971


   literaltype    ::=  B | O | X | E | A

   string         ::=  from 0 to 256 characters

   control        ::=  :  options | <null>

   options        ::=  S(where) | F(where) | U(where) |
                       S(where) , F(where) |
                       F(where) , S(where)

   where          ::=  arithmeticexpression | R(arithmeticexpression)



ALTERNATE SPECIFICATION OF FORM MACHINE SYNTAX

                                   infinity
form                    ::=  {rule}
                                   1
                                      1         1          1
rule                    ::=  {INTEGER}   {terms}   {:terms} ;
                                      0         0          0
                                         infinity
terms                   ::=  term {,term}
                                         0
                                                      1
term                    ::=  identifier | {identifier}   descriptor
                                                      0
                             | comparator
                                                    1
descriptor              ::=  ({arithmeticexpression}  , datatype ,
                                                    0
                                    1                     1           1
                             {value} ,  {lengthexpression}  {:options}
                                    0                     0           0
                                                                 1
comparator              ::=  (value  connective  value {:options} ) |
                                                                 0
                                                              1
                             (identifier .<=. value {:options} )
                                                              0
connective              ::=  .LE. | .LT. | .GE. | .GT. | .EQ. | .NE.

lengthexpression        ::=  # | arithmeticexpression

datatype                ::=  B | O | X | E | A

value                   ::=  literal | arithmeticexpression



Anderson, et al.                                                [Page 9]

RFC 138               Data Reconfiguration Service          April 1971


                                                         infinity
arithmeticexpression    ::=  primary  {operator  primary}
                                                         0
operator                ::= + | - | * | /

primary                 ::=  identifier | L(identifier) |
                             V(identifier) | INTEGER
                                                      256
literal                 ::=  literaltype  "{CHARACTER}   "
                                                      0
literaltype             ::=  B | O | X | A | E
                                                 1
options                 ::=  S(where) {,F(where)}  |
                                                 0
                                                 1
                             F(where) {,S(where)}  | U(where)
                                                 0

where                   ::=  arithmeticexpression |
                             R(arithmeticexpression)
                                                     3
identifier              ::=  ALPHABETIC  {ALPHAMERIC}
                                                     0

FORMS

   A form is an ordered set of rules.

         form ::=  rule | rule form

   The current rule is applied to the current position of the input
   stream.  If the (input stream part of a) rule fails to correctly
   describe the contents of the current input then another rule is made
   current and applied to the current position of the input stream.  The
   next rule to be made current is either explicitly specified by the
   current term in the current rule or it is the next sequential rule by
   default.  Flow of control is more fully described under TERM AND RULE
   SEQUENCING.

   If the (input stream part of a) rule succeeds in correctly describing
   the current input stream, then some data may be emitted at the
   current position in the output stream according to the rule.  The
   input and output stream pointers are advanced over the described and
   emitted data, respectively, and the next rule is applied to the now
   current position of the input stream.

   Application of the form is terminated when an explicit return
   (R(arithmeticexpression)) is encountered in a rule.  The user and



Anderson, et al.                                               [Page 10]

RFC 138               Data Reconfiguration Service          April 1971


   server connections are closed and the return code
   (arithmeticexpression) is sent to the originating user.

RULES

   A rule is a replacement, comparison, and/or an assignment operation
   of the form shown below.

         rule ::= label  inputstream  outputstream ;

   A label is the name of a rule and it exists so that the rule may be
   referenced elsewhere in the form for explicit rule transfer of
   control.  Labels are of the form below.

         label ::=  INTEGER | <null>

   The optional integer labels are in the range 0 >= INTEGER >= 9999.
   The rules need not be labeled in ascending numerical order.

TERMS

   The inputstream (describing the input stream to be matched) and the
   outputstream (describing data to be emitted in the output stream)
   consist of zero or more terms and are of the form shown below.

         inputstream   ::=  terms | <null>
         outputstream  ::=  :terms | <null>
         terms         ::=  term | terms , term

   Terms are of one of four formats as indicated below.

         term ::=  identifier | identifier  descriptor |
                   descriptor | comparator

Term Format 1

   The first term format is shown below.

         identifier

   The identifier is a symbolic reference to a previously identified
   term (term format 2) in the form.  It takes on the same attributes
   (value, length, type) as the term by that name.  Term format 1 is
   normally used to emit data in the output stream.

   Identifiers are formed by an alpha character followed by 0 to 3
   alphameric characters.




Anderson, et al.                                               [Page 11]

RFC 138               Data Reconfiguration Service          April 1971


Term Format 2

   The second term format is shown below.

         identifier descriptor

   Term format 2 is generally used as an input stream term but can be
   used as an output stream term.

   A descriptor is defined as shown below.

         descriptor ::= (replicationexpression, datatype,
                        valueexpression, lengthexpression
                        control)

   The identifier is the symbolic name of the term in the usual
   programming language sense.  It takes on the type, length, and value
   attributes of the term and it may be referenced elsewhere in the
   form.

   The replication expression is defined below.

         replicationexpression ::= arithmeticexpression | <null>
         arithmeticexpression ::= primary | primary operator
                                       arithmeticexpression
         operator ::= + | - | * | /
         primary ::= identifier | L(identifier) | V(identifier) |
                     INTEGER

   The replication expression is a repeat function applied to the
   combined data type and value expression.  It expresses the number of
   times that the value (of the data type/value expression) is to be
   repeated within the field length denoted by the data type/length
   expression.

   A null replication expression has the value of one.  Arithmetic
   expressions are evaluated from left-to-right with no precedence.  (It
   is anticipated that this interpretation might be changed, if
   necessary.)

   The L(identifier) is a length operator that generates a 32-bit binary
   integer corresponding to the length of the term named.  The
   V(identifier) is a value operator that generates a 32-bit binary
   integer corresponding to the value of the term named.  (See
   Restrictions and Interpretations of Term Functions.)  The value
   operator is intended to convert character strings to their numerical
   correspondents.




Anderson, et al.                                               [Page 12]

RFC 138               Data Reconfiguration Service          April 1971


   The data type is defined below.

             datatype ::= B | O | X | E | A

   The data type describes the kind of data that the term represents.
   (It is expected that additional data types, such as floating point
   and user-defined types, will be added as needed.)

        Data Type         Meaning              Unit Length

            B             Bit string              1 bit
            O             Bit string              3 bits
            X             Bit string              4 bits
            E             EBCDIC character        8 bits
            A             Network ASCII character 8 bits

        The value expression is defined below.

                 valueexpression ::= value | <null>
                 value ::= literal | arithmeticexpression
                 literal ::= literaltype "string"
                 literaltype ::= B | O | X | E | A

   The value expression is the unit value of a term expressed in the
   format indicated by the data type.  It is repeated according to the
   replication expression, in a field whose length is constrained by the
   length expression.

   A null value expression in the input stream defaults to the data
   present in the input stream.  The data must comply with the datatype
   attribute, however.

   A null value expression generates padding according to Restrictions
   and Interpretations of Term Functions.

   The length expression is defined below.

         lengthexpression ::= # | arithmeticexpression | <null>

   The length expression states the length of the field containing the
   value expression as expanded by the replication expression.  If the
   value of the length expression is less then the length implied by the
   expanded value expression, then the expanded value expression is
   truncated, see Restrictions and Interpretations of Term Functions.

   The terminal symbol # means an arbitrary length, explicitly
   terminated by the value of the next term.  The # is legal only in the
   input stream and not in the output stream.



Anderson, et al.                                               [Page 13]

RFC 138               Data Reconfiguration Service          April 1971


   If the length expression is less than or equal to zero, the term
   succeeds but the appropriate stream pointer is not advanced.
   Positive lengths cause the appropriate stream pointer to be advanced
   if the term otherwise succeeds.

   Control is defined under TERM AND RULE SEQUENCING.

Term Format 3

   Term format 3 is shown below.

         descriptor

   It is identical to term format 2 with the omission of the identifier.
   Term format 3 is generally used in the output stream.  It is used in
   the input stream where input data is to be passed over but not
   retained for emission or later reference.

Term Format 4

   The fourth term format is shown below.

         comparator    ::= (value connective value control) |
                           (identifier .<=. value control)
         value         ::= literal | arithmeticexpression
         literal       ::= literaltype "string"
         literaltype   ::= B | O | X | E | A
         string        ::= from 0 to 256 characters
         connective    ::= .LE. | .LT. | .GE. | .GT. | .EQ. | .NE.

   The fourth term format is used for assignment and comparison.

   The assignment operator .<=. assigns the value to the identifier.
   The connectives have their usual meaning.  Values to be compared must
   have the same type and length attributes or an error condition arises
   and the form fails.

The Application of a Term

   The elements of a term are applied by the following sequence of
   steps.

         1.  The data type and value expression together specify a unit
             value, call it x.

         2.  The replication expression specifies the number of times x
             is to be repeated (or copied) in concatenated fashion.  The
             value of the concatenated xs becomes, say, y of length L1.



Anderson, et al.                                               [Page 14]

RFC 138               Data Reconfiguration Service          April 1971


         3.  The data type and the length expression together specify a
             field length of the input area (call it L2) that begins at
             the current stream pointer position.

         4.  The value of y is truncated to y' if L1 > L2.  Call the
             truncated length L1'.

         5.  If the term is an input stream term, then the value y' of
             length L1' is compared to the input value beginning at the
             current input pointer position.

         6.  If the values are identical over the length L1' then the
             input value of length L2 (may be greater than L1') starting
             at the current pointer position in the input area, becomes
             the value of the term.

   In an output stream term, the procedure is the same except that the
   source of input is the value of the term(s) named in the value
   expression and the data is emitted in the output stream.

   The above procedure is modified to include a one term look-ahead
   where lengths are indefinite because of the arbitrary symbol, #.

Restrictions and Interpretations of Term Functions

   1.  Terms specifying indefinite lengths, through the use of the #
         symbol must be separated by some type-specific data such as a
         literal.  (A literal isn't specifically required, however.  An
         arbitrary number of ASCII characters could be terminated by a
         non-ASCII character.)  # is legal only in the input stream, not
         in the output stream.

   2.  Truncation and padding is as follows:
         a)  Character to character (A <--> E) conversion is left
             justified and truncated or padded on the right with blanks.
         b)  Character to numeric and numeric to numeric conversions are
             right-justified and truncated or padded on the left with
             zeros.
         c)  Numeric to character conversion is right-justified and
             left-padded with blanks.

   3.  The following are ignored in a form definition over the control
         connection.
         a)  TAB, carriage return, etc.
         b)  blanks except within quotes.
         c)  /* string */ is treated as comments except within quotes.

   4.  The following defaults prevail where the term part is omitted.



Anderson, et al.                                               [Page 15]

RFC 138               Data Reconfiguration Service          April 1971


         a)  The replication expression defaults to one.
         b)  The data type defaults to type B.
         c)  The value expression of an input stream term defaults to
             the value found in the input stream, but the input stream
             must conform to data type and length expression.  The value
             expression of an output stream term defaults to padding
             only.
         d)  The length expression defaults to the size of the quantity
             determined by replication expression, data type, and value
             expression.
         e)  Control defaults to the next sequential term if a term is
             successfully applied; else control defaults to the next
             sequential rule.  If _where_ evaluates to an undefined
             _label_ the form fails.

   5.  Arithmetic expressions are evaluated left-to-right with no
         precedence.

   6.  The following limits prevail.

         a)  Binary lengths are <= 32 bits
         b)  Character strings are <= 256 8-bit characters
         c)  Identifier names are <= 4 characters
         d)  Maximum number of identifiers is <= 256
         e)  Label integers are >= 0 and <= 9999

   7.  Value and length operators product 32-bit binary integers.  The
         value operator is currently intended for converting A or E type
         decimal character strings to their binary correspondents.  For
         example, the value of E'12' would be 0......01100.  The value
         of E'AB' would cause the form to fail.




















Anderson, et al.                                               [Page 16]

RFC 138               Data Reconfiguration Service          April 1971


TERM AND RULE SEQUENCING

   Sequencing may be explicitly controlled by including control in a
   term.

        control ::=  :options | <null>
        options ::=  S(where) | F(where) | U(where)
                     S(where) , F(where) |
                     F(where) , S(where)

        where   ::=  arithmeticexpression | R(arithmeticexpression)

   S, F, and U denote success, fail, and unconditional transfers,
   respectively.  _Where_ evaluates to a _rule_ label, thus transfer can
   be effected from within a rule (at the end of a term) to the
   beginning of another rule.  R means terminate the form and return the
   evaluated expression to the initiator over the control connection (if
   still open).

   If terms are not explicitly sequenced, the following defaults
   prevail.

   1)  When a term fails go to the next sequential rule.
   2)  When a term succeeds go to the next sequential
       term within the rule.
   (3) At the end of a rule, go to the next sequential
       rule.

   Note in the following example, the correlation between transfer of
   control and movement of the input pointer.

        1   XYZ(,B,,8:S(2),F(3)) : XYZ ;
        2   . . . . . . .
        3   . . . . . . .

   The value of XYZ will never be emitted in the output stream since
   control is transferred out of the rule upon either success or
   failure.  If the term succeeds, the 8 bits of input will be assigned
   as the value of XYZ and rule 2 will then be applied to the same input
   stream data.  That is, since the complete rule 1 was not successfully
   applied, then the input stream pointer is not advanced.










Anderson, et al.                                               [Page 17]

RFC 138               Data Reconfiguration Service          April 1971


IV.  EXAMPLES

REMARKS

   The following examples (forms and also single rules) are simple
   representative uses of the Form Machine.  The examples are expressed
   in a term-per-line format only to aid the explanation.  Typically, a
   single rule might be written as a single line.

FIELD INSERTION

   To insert a field, separate the input into the two terms to allow the
   inserted field between them.  For example, to do line numbering for a
   121 character/line printer with a leading carriage control character,
   use the following form.

   (NUMB.<=>.1);       /*initialize line number counter to one*/
   1 CC(,E,,1:F(R(99))),  /*pick up control character and save
                            as CC*/
                          /*return a code of 99 upon exhaustion*/
   LINE(,E,,121 : F(R(98)))    /*save text as LINE*/
   :CC,               /*emit control character*/
   (,E,NUMB,2),       /*emit counter in first two columns*/
   (,E,E".",1),       /*emit period after line number*/
   (,E,LINE,117),     /*emit text, truncated in 117 byte field*/
   (NUMB.<=.NUMB+1:U(1));    /*increment line counter and go to
                               rule one*/;;

DELETION

   Data to be deleted should be isolated as separate terms on the left,
   so they may be omitted (by not emitting them) on the right.

   (,B,,8),           /*isolate 8 bits to ignore*/
   SAVE(,A,,10)       /*extract 10 ASCII characters from
                        input stream*/
   :(,E,SAVE,);      /*emit the characters in SAVE as EBCDIC
                       characters whose length defaults to the
                       length of SAVE, i.e., 10, and advance to
                       the next rule*/

   In the above example, if either input stream term fails,
   the next sequential rule is applied.

VARIABLE LENGTH RECORDS

   Some devices, terminals and programs generate variable length
   records.  To following rule picks up variable length EBCDIC records



Anderson, et al.                                               [Page 18]

RFC 138               Data Reconfiguration Service          April 1971


   and translates them to ASCII.

   CHAR(,E,,#),       /*pick up all (an arbitrary number of)
                        EBCDIC characters in the input stream*/
   (,X,X"FF",2)       /*followed by a hexadecimal literal,
                        FF (terminal signal)*/
   :(,A,CHAR,),       /*emit them as ASCII*/
   (,X,X"25",2);      /*emit an ASCII carriage return*/

STRING LENGTH COMPUTATION

   It is often necessary to prefix a length field to an arbitrarily long
   character string.  The following rule prefixes an EBCDIC string with
   a one-byte length field.

   Q(,E,,#),          /*pick up all EBCDIC characters*/
   TS(,X,X"FF",2)     /*followed by a hexadecimal literal, FF*/
   :(,B,L(Q)+2,8),    /*emit the length of the characters
                        plus the length of the literal plus
                        the length of the count field itself,
                        in an 8-bit field*/
   Q,                 */emit the characters*/
   TS;                */emit the terminal*/

TRANSPOSITION

   It is often desirable to reorder fields, such as the following
   example.

   Q(,E,,20), R(,E,,10) , S(,E,,15), T(,E,,5) : R, T, S, Q ;

   The terms are emitted in a different order.

CHARACTER PACKING AND UNPACKING

   In systems such as HASP, repeated sequences of characters are packed
   into a count followed by the character, for more efficient storage
   and transmission.  The first form packs multiple characters and the













Anderson, et al.                                               [Page 19]

RFC 138               Data Reconfiguration Service          April 1971


   second unpacks them.
   /*form to pack EBCDIC streams*/
   /*returns 99 if OK, input exhausted*/
   /*returns 98 if illegal EBCDIC*/
   /*look for terminal signal FF which is not a legal EBCDIC*/
   /*duplication count must be 0-254*/
   1 (,X,X"FF",2 : S(R(99))) ;
   /*pick up the EBCDIC and initialize count/*
     CHAR(,E,,1 : F(R(98))) , (CNT .<=. 1) ;
   /*count consecutive EBCDICs like CHAR*/
   2 (,E,CHAR,1 : F(3)) , (CNT .<=. CNT+1 : U(2)) ;
   /*emit count and current character*/
   3 : (,B,CNT,8), CHAR, (:U(1));
   /*end of form*/;;

   /*form to unpack EBCDIC streams*/
   /*look for terminal*/
   1 (,X,X"FF",2 : S(R(99))) ;
   /*emit character the number of times indicated*/
   /*by the counter contents*/
   CNT(,B,,8), CHAR(,E,,1) : (CNT,E,CHAR,CNT:U(1));
   /*failure of form*/
   (:U(R(98))) ;;


V.  PROPOSED USES OF DATA RECONFIGURATION SERVICE

   The following are some proposed uses of the DRS that were submitted
   by the sites indicated.

   UCLA
   1.  Pack/unpack text files.
   2.  Preprocessor to scan META compiler input.
   3.  Perhaps graphics.

   MIT
   1.  Reformatting within file transfer service.
   2.  Character conversions.
   3.  Possible graphics service (Evans and Sutherland output
       format).
   4.  Reformat arguments of subroutines remote to each other.

   U. OF ILLINOIS
   1.  Dependent upon remote use of DRS for many remote
       services.

   SDC
   1.  Would be essential to data transfer in general.



Anderson, et al.                                               [Page 20]

RFC 138               Data Reconfiguration Service          April 1971


   2.  Could be used in relation to data management language.

   UCSB
   1.  Checkout of I/O formats of file system.
   2.  Debugging Network services in general.
   3.  Mapping their services into future standards.

   RAND
   1.  To describe RJO/RJE message formats at UCSB.
   2.  To describe RJS message formats at UCLA.
   3.  To adapt Network to existing services, in general.

   MITRE
   1.  Character conversions.
   2.  Testing data formats going into data bases for correct
       field formatting.

   VI.  IMPLEMENTATION PLANS

   Four sites currently plan to implement and offer the service on an
   experimental basis.

   1.  MIT    Implementation of forms interpreter in MIDAS
              (assembly).  Perhaps Tree Meta compiler of
              forms.  Implementation on PDP-10.

   2.  UCLA   Implementation on SIGMA-7 employing META-7
              to compile forms.

   3.  UCSB   Implementation on 360/75.

   4.  RAND   Initial implementation on 360/65; compiler to be written
               in graphics CPS; compiled intermediate forms to be
               interpreted by assembler language subroutine.  Later
               implemented on PDP-10.

   In addition to the above sites, the University of Illinois and Mitre
   plan to experiment with the service.













Anderson, et al.                                               [Page 21]

RFC 138               Data Reconfiguration Service          April 1971


                                APPENDIX A

Note 1 to the DRS Working Group

   As you recall, we spent considerable time in discussing the use and
   meaning of the arbitrary symbol, #.  To summarize, it was clear that
   inclusion of the # in both replication and length expressions led to
   ambiguities.  We settled on its restricted use in the length
   expression of an input term, although no one was entirely satisfied
   with this definition.

   Recently, Jim White has again commented on the #.  Jim feels that it
   is curious that one can pick up an arbitrary number of EBCDIC
   characters, for example, but can't pick up an arbitrary number of
   specific EBCDIC characters such as EBCDIC A's.  Jim feels that a more
   natural way to interpret the length, value, and replication
   expressions would be as the IBM OS assembler interprets the
   attributes of the pseudo instruction, define constant (CD).

   The IBM OS assembler uses the following format.

        1             2              3           4
   duplication       type        modifiers   nominal value
     factor

   The duplication factor, if specified, causes the constant to be
   generated the number of times indicated by the factor.  The type
   defines the type of constant being specified.  Modifiers describe the
   length, scaling, and exponent of the constant.  Nominal value
   supplies the constant described by the subfields that precede it.

   Assume that we use the # only as a duplication factor (replication
   expression).  Hence, in the example of the form to pack EBCDIC
   characters, the counter and looping can be eliminated.

   CHAR(,E,,1) ;
   LEN(#,#,CHAR,1) : (,B,L(LEN)+1,*) , CHAR ;

   The interpretation is that the data type, length expression, and
   value expression make up the unit value.  This quantity can then be
   replicated.  As our document now stands, only the data type and value
   expression make up the unit value.

   The application of a term according to Jim's suggestion is as
   follows.
   1.  The data type, value expression, and length expression together
       specify a unit value, call it x.




Anderson, et al.                                               [Page 22]

RFC 138               Data Reconfiguration Service          April 1971


   2.  The replication expression specifies the number of times x is to
       be repeated.  The value of the concatenated xs becomes y of
       length L.
   3.  If the term is an input stream term then the value beginning at
       the current input pointer position.
   4.  If the input value satisfies the constraints of y over length L
       then the input value of length L becomes the value of the term.

Note 2 to the DRS Working Group

   There has been recent debate of whether the input pointer should be
   advanced upon successful completion of a rule (as it now is defined)
   or upon successful completion of each term.  See the example on page
   22.  If the input pointer is advanced upon successful completion of a
   term, then rules become equivalent to terms.

   I would like to for us to discuss at the SJCC both the term
   attributes and the input pointer advance issues.

                                                John


       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Katsunori Tanaka 4/99 ]



























Anderson, et al.                                               [Page 23]