File: rfc122.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 (1179 lines) | stat: -rw-r--r-- 47,638 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






Network Working Group                                     James E. White
Request for Comments: 122                               UC Santa Barbara
NIC 5834                                                   26 April 1971


                   NETWORK SPECIFICATIONS FOR UCSB's

                       SIMPLE-MINDED FILE SYSTEM


                                CONTENTS
                                                               Page

          I.   Preface........................................   3

         II.   Implementation.................................   3

        III.   Login..........................................   3

         IV.   Service Offered................................   4

          V.   Primitive File Operations......................   6

               V.A.  Allocate File (ALF)......................   6

               V.B.  Update File (UDF)........................   7

               V.C.  Replace File (RDF).......................   8

               V.D.  Retrieve File (RTF)......................   9

               V.E.  Space File (SPF).........................   9

               V.F.  Delete File (DLF)........................  10

               V.G.  Rename File (RNF)........................  10

               V.H.  File No Operation (FNO)..................  10

               V.I.  No Operation (NOP).......................  11

         VI.   Input Stream Format............................  11

        VII.   Output Stream Format...........................  16







J. White                                                        [Page 1]

RFC 122                Simple-Minded file System              April 1971


        FIGURES
                                                               Page

        Figure 1.  Filename/Password Character Sets...........   5

        Figure 2.  Command Op Codes...........................  12

        Figure 3.  Defined Command Fields.....................  13

        Figure 4.  Definition of Command FLAGS Bits...........  14

        Figure 5.  Defined Command Response Fields............  18

        Figure 6.  Completion Codes...........................  19





































J. White                                                        [Page 2]

RFC 122                Simple-Minded file System              April 1971


I.   Preface

   UCSB will provide file storage for Network users.  UCSB's Simple
   Minded File System (SMFS) is addressed as socket number X'401', site
   3.  No accounting parameters are required.  This document is intended
   to provide programmers with the information necessary to communicate
   with SMFS which conducts all Network transactions trough its NCP
   which operates under the Host-Host protocol of August 3, 1970.*

II.  Implementation

   The following information is not essential to use of SMFS but may be
   of interest.  SMFS will store user's files on IBM 2316 disk packs,
   each with 29M 8-bit bytes of storage capacity.  UCSB has two 2314
   units, each with eight drives on-line.  Initially, one drive will be
   allocated for Network storage, and the appropriate pack will always
   be mounted an that drive, and hence accessible to SMFS without
   operator intervention.  UCSB estimates that for the next year it will
   have up to four drives that it can devote to Network use.  The
   second, third, and fourth drives will be allocated only as the need
   arises.  SMFS is written to accommodate any number of on-line drives
   without modification.

   If necessary, UCSB will investigate the possibility of making one of
   the four drives a come-and-go drive on which one of a number of packs
   can be mounted as required.  Hence, the potential exists for
   increased storage capacity with an accompanying increase in access
   time.

   Files stored with SMFS will be backed up to tape daily.  The back-up
   tape(s) will be off-line and available only in case the on-line
   copies are destroyed.

   In no sense does USB expect to become _the_ file storage node of the
   Network; it hasn't the capacity.  UCSB _is_ equipped, however, to
   make a limited amount of secondary storage immediately available to
   the Network community.

III.  Login

   SMFS can simultaneously service any number of Network users up to
   some assembly-parameters maximum (currently ten).  A potential user
   must establish a pair of Network connections

*At the time of this writing, the NCP modifications of RFC #107 have not
as yet been implemented at UCSB.





J. White                                                        [Page 3]

RFC 122                Simple-Minded file System              April 1971


   (i.e., one full-duplex connection) to SMFS by executing a standard
   ICP to socket X'401', site 3.  SMFS always listens on that socket.
   It will accept any call it receives -- say from the user's receive
   socket 'm' -- and over the connection thus established transmit a
   32-bit receive socket number (call it 'n'), and then close the
   connection.  SMFS will then issue two connection requests -- one
   involving its receive socket 'n' and the user's send socket 'm+l', in
   other involving its send socket 'n+l' and the user's receive socket
   'm'.  Once these two connections have been established, the user will
   be considered logged in.  A deviation from the Initial Connection
   Protocol will occur only if SMFS or its NCP has insufficient
   resources to support another connection.

   SMFS will maintain its connections to the user indefinitely.  It will
   voluntarily terminate its connections to the user only if (1) a bad
   op code is encountered in a user command (see Section VI), or (2)
   closing one of the connections is required to signal end-of-data (see
   Section V.D.).  Barring such an occurrence, the user should close his
   connections to SMFS when through, at which time SMFS will consider
   the user logged out.

   In the discussion to follow, the following terms are used.  The
   connections on which the user transmits data to and receives data
   from SMFS are designated the input and output connections,
   respectively (i.e., SMFS's rather than the user's point of view is
   adopted).  The string of bits which passes from the user to SMFS over
   the input connection during the life of that connection is called the
   _input stream_; the string of bits which passes from SMFS to the user
   over the output connection during the life of that connection is
   called the _output stream_.

IV.  Service Offered

   SMFS will provide storage for sequential, binary files of length
   greater than or equal to an assembly-parameter minimum (currently one
   bit) and less than or equal to an assembly-parameter maximum
   (currently 25 million bits).  There is no restriction on the contents
   of the file.

   Every file stored with SMFS has a _filename_, which may be any string
   of from one to 36, 8-bit characters chosen from the set:

        { A,...,Z,0,...9,blank }








J. White                                                        [Page 4]

RFC 122                Simple-Minded file System              April 1971


   Graphic              EBCDIC Code (Hex)    ASCII Code (Hex)

   UC     LC                UC     LC            UC     LC

   A     a                  C1     81            41     61
   B     b                  C2     82            42     62
   C     c                  C3     83            43     63
   D     d                  C4     84            44     64
   E     e                  C5     85            45     65
   F     f                  C6     86            46     66
   G     g                  C7     87            47     67
   H     h                  C8     88            48     68
   I     i                  C9     89            49     69
   J     j                  D1     91            4A     6A
   K     k                  D2     92            4B     6B
   L     l                  D3     93            4C     6C
   M     m                  D4     94            4D     6D
   N     n                  D5     95            4E     6E
   O     o                  D6     96            4F     6F
   P     p                  D7     97            50     70
   Q     q                  D8     98            51     71
   R     r                  D9     99            52     72
   S     s                  E2     A2            53     73
   T     t                  E3     A3            54     74
   U     u                  E4     A4            55     75
   V     v                  E5     A5            56     76
   W     w                  E6     A6            57     77
   X     x                  E7     A7            58     78
   Y     y                  E8     A8            59     79
   Z     z                  E9     A9            5A     7A


   0     -                  F0      -             30     -
   1     -                  F1      -             31     -
   2     -                  F2      -             32     -
   3     -                  F3      -             33     -
   4     -                  F4      -             34     -
   5     -                  F5      -             35     -
   6     -                  F6      -             36     -
   7     -                  F7      -             37     -
   8     -                  F8      -             38     -
   9     -                  F9      -             39     -

   blank -                  40      -             20     -

                                 Figure 1

                     Filename/Password Character Sets



J. White                                                        [Page 5]

RFC 122                Simple-Minded file System              April 1971


   Filenames may be specified by the user in either EBCDIC or ASCII (see
   Figure 1), and the characters A,...,Z may be either upper- or lower-
   case.  However, the acceptance by SMFS of both upper- and lower-case,
   and both EBCDIC and ASCII, is provided only as a convenience to the
   user.  In particular, such distinctions don't increase the number of
   unique filenames that can be generated; the filenames 'FILE NUMBER 1'
   and 'file number 1', in EBCDIC or ASCII, designate the same file.

   Every file stored with SMFS may optionally be protected against
   unauthorized retrieval and/or modification.  When a file is created,
   the user may associate with it a _modification password_ and/or an
   _access password_.  Thereafter, SMFS will demand that the appropriate
   password be supplied before the file is modified or retrieved,
   respectively.  Since SMFS protects each file independently against
   unauthorized modification and retrieval, a group of users can be
   given access to a file while a single individual retains the
   exclusive right to modify it.  If no password is defined for a
   particular type of reference to a file, then such references are
   unrestricted.  Passwords have the same attributes as filenames --
   same length restrictions and same character sets.

   Because of the manner in which SMFS writes files onto secondary
   storage, it must insure that while one user is modifying a file, no
   other user is simultaneously either modifying or retrieving the same
   file.  This requirement is effected by a mechanism internal to SMFS
   and hence transparent to users, with the exception that when a user
   attempts to retrieve or modify a file currently being modified by
   another user, SMFS will delay action upon the request until the
   current modification is complete.  There is no restriction on the
   number of users which may concurrently retrieve the same file.

V.   Primitive File Operations

   SMFS recognizes and will execute the following primitive file
   operations:

V.A.  Allocate File (ALF)

   SMFS regards the reservation of filename, the assignment of
   passwords, and the reservation of secondary storage as an operation
   distinct from that of transmitting the file's contents.  The
   operation is called _file allocation_, abbreviated ALF.  In
   allocating a file, the user specifies the filename to be assigned to
   it, the access password (if any), and the estimated size of the file
   in bits.  SMFS checks the proposed filename to insure that it doesn't
   duplicate that of an existing file.  SMFS also checks to insure that
   it has sufficient secondary storage available to accommodate the new




J. White                                                        [Page 6]

RFC 122                Simple-Minded file System              April 1971


   file.  If both requirements are met, SMFS allocates the file; the
   filename is reserved, secondary storage is reserved, and the password
   information is recorded.

   In reserving secondary storage for a file, SMFS adds its estimate of
   its overhead in storing the file to the user-declared size of the
   file.  In general, the user should slightly over-estimate the size of
   his file at allocation.  SMFS allocates a fixed amount of storage on
   the basis of that estimate, an amount which cannot be increased
   later.  SMFS's actual overhead in storing a file is a function of the
   manner in which the contents of the file are transmitted by the user.
   The overhead is minimal when the file is transmitted in a single
   series of operations (see Section VI) and increases as the number of
   operations increases.  It is the overhead associated with single-
   series transmission that SMFS adds to the file size specified by the
   user to determine the amount of storage to allocate.  Hence, for
   multiple-series transmission, the overhead will have been
   underestimated.

V.B.  Update File (UDF)

   The operation of transmitting part or all of a previously allocated
   file's contents for storage by SMFS is called _updating_ the _file_
   (UDF).  The user specifies the filename of the file to be updated,
   the modification password if required, the amount of data in bits to
   be added to the file, and finally the data itself.  SMFS locates the
   file on secondary storage, checks the password for validity, if
   appropriate, and adds the data to the file.  SMFS considers the
   update complete when either the specified number of bits have been
   extracted from the input stream and stored, or when the user
   terminates transmission by closing the connection.

   The data transmitted in a UDF operation is _concatenated_ to the
   current contents of the file.  Boundaries between updates are
   transparent to the user when the file is retrieved.  Hence, for
   example, the contents of a file might be transmitted to SMFS in two
   distinct UDF operations, and later retrieved in a single RTF
   operation (see Section V.D.).  The user should view a file stored
   with SMFS as a potentially very long bit string which may be
   transmitted to SMFS in any number of variable-length _segments_, and
   is retrievable in any number of variable-length segments, with the
   manner of segmentation chosen during retrieval independent of that
   selected during the updating process.

   The user may optionally request that SMFS 'remember' the manner in
   which a file was updated, i.e., along with the data, store sufficient
   information to reconstruct segment boundaries at retrieval time.
   Such a file is said to be _formatted_.  In retrieving a formatted



J. White                                                        [Page 7]

RFC 122                Simple-Minded file System              April 1971


   file, the user, rather than requesting that SMFS transmit the next
   'n' bits of the file as he would do for an unformatted file (see
   Section V.D.), requests that SMFS transmit the next segment of the
   file; it is then SMFS's responsibility to supply the length of the
   segment.  Hence, the notion of a _logical record_ is introduced.

   Of course, since the user may format the contents of a file in any
   way he chooses, he can embed record-length information in the data
   itself.  Hence, the user can implement a record structure in a way
   that's transparent to SMFS.  This scheme, however, requires during
   retrieval that, for each logical record retrieved, the user fetch
   first the length field and then, using the length as an operand,
   fetch the data itself.  In this kind of arrangement, the retrieval
   rate is apt to suffer.  However, by allowing SMFS knowledge of
   logical-record boundaries, the feedback loop is effectively shortened
   (SMFS being closer to the file); hence, the potential exists for an
   increased retrieval rate.

   If the user intends that a file be formatted, he must so specify in
   every update and every retrieve operation referencing that file.
   SMFS in no way flags a file to indicate that it is formatted.  Hence,
   if the user invokes the option during retrieval without having done
   so when the file was stored, results will be erroneous.  Furthermore,
   if an update of a formatted file is terminated before the bit count
   for the operation is exhausted (i.e., because the user closed the
   connection), retrieval results will again be erroneous.

V.C.  Replace File (RPF)

   The replace-file (RPF) operation is identical to UDF, except that the
   new file segment, rather than being concatenated to the existing
   file, _replaces_ the entire contents of the file.  The previous
   contents of the file are lost, and the new segment becomes the only
   segment in the file.

   RPF may be used to rewrite an existing file.  If the rewritten file
   is to contain just a single segment, that segment may be transmitted
   to SMFS in an RPF operation.  Otherwise, the first segment of the new
   file must be transmitted in an RPF operation, and all succeeding
   segments in UDF operations.  Alternately, a dummy (bit count of zero)
   RPF operation may be inserted before the first real segment is
   transmitted; all segments of the file may then be transmitted in UDF
   operations.








J. White                                                        [Page 8]

RFC 122                Simple-Minded file System              April 1971


V.D.  Retrieve File (RTF)

   The operation which retrieves all or part of a file's contents is
   called file retrieval (RTF).  The user specifies the filename of the
   file to be retrieved, the access password if required, and the amount
   of data in bits to be fetched from the file.  SMFS locates the file
   on secondary storage, checks the password for validity (if
   appropriate), and copies the bit count and the requested file segment
   into the output stream.  SMFS considers the retrieval complete when
   either the requested number of bits have been placed in the output
   stream, or when the contents of the file are exhausted.  In this
   latter case, SMFS closes the connection to signal end-of-data to the
   user.

   Successive RTF operations referencing the same file cause successive
   segments of the file to be transmitted, provided that the operations
   are juxtaposed in the input stream (however, NOP's may be
   interspersed anywhere in the input stream).  When a series of RTF
   operations referencing a particular file is broken by an operation
   referencing another file, or by a different type of operation
   involving the same file, the next RTF operation designating the
   original file will cause the _first_ segment of that file to be
   transmitted.  The manner in which the user segments a file for a
   series of retrieve operations need bear no relationship to the
   segmentation scheme employed when the file was updated, nor to that
   employed in previous retrievals.

   If the user elected to have his file formatted by SMFS, he should
   re-invoke the option in the RTF operation, in which case SMFS will
   supply the length of the segment, and place both it and the segment
   itself into the output stream.

V.E.  Space File (SPF)

   Files stored with SMFS are sequential in organization.  That is the
   n+1th segment of the file cannot be retrieved without first
   processing the nth segment.  The user may, however, upon occasion,
   wish to retrieve only selected segments of a file.  This he could do,
   effectively, by retrieving each segment of the file and flushing
   those with which he was currently unconcerned.  To avoid needless
   Network traffic, SMFS provides a mechanism for flushing file segments
   locally.  The operation is called _spacing_ a file (SPF).  It is
   identical to RTF with the exception that transmission of data (but
   not bit count) is suppressed.  SPF operations may be freely inserted
   anywhere within a series of RTF operations designating a particular
   file, with the desired results.





J. White                                                        [Page 9]

RFC 122                Simple-Minded file System              April 1971


V.F.  Delete File (DLF)

   A file may be deleted at any time after allocation.  The user
   specifies the filename of the file to be deleted and the modification
   password if required.  SMFS locates the file on secondary storage,
   checks the password for validity (if appropriate), and, if the
   password is correct, deletes the file.  The filename is made
   available for reassignment, and the secondary storage allocated to
   the file is reclaimed by SMFS.  The contents (if any) of the file are
   lost.

V.G.  Rename File (RNF)

   A file stored with SMFS may be renamed at any time after allocation.
   The user specifies the current filename of the file to be renamed,
   the modification password if any, and the proposed new filename.
   SMFS locates the file on secondary storage, checks the password for
   validity (if appropriate), and assures that the proposed new filename
   is not already assigned to another file.  If these requirements are
   met, the file is renamed, and all subsequent references to the file
   must be by the newly-assigned filename.

   RNF provides a means for protecting a file that must be rewritten in
   its entirety against failures in the Net, or in the sending or
   receiving host.  The strategy is as follows.  Allocate a new file,
   assigning it some temporary name.  Transmit the revised file contents
   in one more UDF and/or RPF operations.  Then delete the original file
   and, using RNF, replace the newly-created file's temporary filename
   with that of the original file.

V.H.  File no Operation (FNO)

   FNO is a dummy operation which is provided for use in terminating a
   series of RTF operations.  Should the user desire to retrieve the
   contents of a file twice in succession, he may do so with a series of
   RTF/SPF operations, followed by a FNO followed by a second series of
   RTF/SPF operations.  Each RTF/SPF operation in the first series will
   retrieve/flush the next segment of the file.  The first operation of
   the second string, since it _is_ the first of a string, will, as
   explained in Section V.D., retrieve/flush the _first_ segment of the
   file.  The remaining operations in the second string will, of course
   retrieve/flush the 2nd, 3rd, etc., segments of the file.  Hence, the
   contents of the file are transmitted twice.  FNO, when it terminates
   such a string of operations, effectively repositions the user to the
   first segment of the file.

   FNO may appear anywhere within the input stream.




J. White                                                       [Page 10]

RFC 122                Simple-Minded file System              April 1971


V.I.  No Operation (NOP)

   This operation is provided _solely_ to aid the user in formatting the
   input stream, and is discarded without further processing whenever it
   is encountered.  In particular, a NOP embedded in a series of RTF
   operations does not terminate the string as FNO does.


VI.  Input Stream Format

   The input stream shall consist of a contiguous string of commands to
   SMFS.  A command type is defined for each of the primitive file
   operations of Section V. Each command has the following general
   format:

  8     16                                              32
 ______________//______//_________//__________//_________________//__
|    |     |        |        |            |         |         |      |
| OP |     |        | ACCESS |MODIFICATION|   NEW   |         |      |
|CODE|FLAGS|FILENAME|PASSWORD|  PASSWORD  | FILENAME|BIT COUNT| DATA |
|____|_____|___//___|__//____|____//______|___//____|_________|__//__|


   where the lengths of fixed-length fields have been indicated in bits.
   Each of the fields 'FILENAME','ACCESS PASSWORD', 'MODIFICATION
   PASSWORD', and 'NEW FILENAME' is further divided into the following
   subfields:

      8         8*LENGTH
   ________________________//___
  |        |                    |
  | LENGTH | FILENAME/PASSWORD  |
  |________|_______________//___|


   where the 'LENGTH' subfield contains the length in 8-bit characters
   of the 'FILENAME/PASSWORD' subfield.

   This is the _general_ format for all SMFS commands.  No one command
   type requires all of the fields specified above.  A particular subset
   of these fields is defined for each type of command, and only those
   fields should appear.  The defined fields for each command type are
   indicated in Figure 3.

   Furthermore, not all of the fields which are defined for a particular
   command type need always appear _explicitly_.  The user should
   envision that SMFS maintains filename, password, and bit-count
   accumulators.  Every time a filename (or new filename),



J. White                                                       [Page 11]

RFC 122                Simple-Minded file System              April 1971


   access/modification password, or bit count appears explicitly in the
   input stream, it is saved in the appropriate accumulator (a null
   password -- designated by setting Bits 0,3 or Bits 8,11 to zero
   (Figure 4) -- should be thought of as appearing explicitly).  The
   user may cause a defined field to _default_ to the current contents
   of the appropriate accumulator by turning on the appropriate bin in
   the flags field (see Figure 4).  When a field defaults in this
   manner, that field is said to appear _implicitly_ in the command.

         NOP                        0                 No operation.

         FNO                        1                 File no operation.

         ALF                        2                 Allocate file.

         UDF                        3                 Update File.

         RPF                        4                 Replace File.

         RTF                        5                 Retrieve File.

         SPF                        6                 Space File.

         DLF                        7                 Delete File.

         RNF                        8                 Rename File.

                                Figure 2
                             Command Op codes

   The three accumulators are initially empty and hence an attempt to
   default a field in the first command in the input stream illicits an
   error indication.  A field of the appropriate type must appear once
   explicitly in the input stream before the corresponding accumulator
   is considered defined.  Furthermore, whenever SMFS detects an invalid
   filename or password (i.e., improper length or deviation from the
   character set) in the input stream, the appropriate accumulator is
   left empty again.

   SMFS allows operations on several files to be interleaved in the
   input stream by including in its command formats provision for
   explicitly specifying filename and password information in each
   command.  When many operations involving the same file appear
   sequentially in the input stream, the user need only let the
   appropriate fields default in all but the first command, avoiding
   re-transmission of what would otherwise be redundant parameters.





J. White                                                       [Page 12]

RFC 122                Simple-Minded file System              April 1971


                                          M
                                          O
                                          D
                                          I
                                          F
                                          I
                                  A       C
                                  C       A
                                  C       T
                                  E       I      N
                                  S       O      E
                                  S       N      W
                                                       B
                            F     P       P      F     I
            O               I     A       A      I     T
            P               L     S       S      L
                    F       E     S       S      E     C
            C       L       N     W       W      N     O     D
            O       A       A     O       O      A     U     A
            D       G       M     R       R      M     N     T
            E       S       E     D       D      E     T     A
   _____________________________________________________________
   ALF      X       X       X     X       X            X
   _____________________________________________________________
   UDF      X       X       X             X            X     X
   _____________________________________________________________
   RPF      X       X       X             X            X     X
   _____________________________________________________________
   RTF      X       X       X     X                    X
   _____________________________________________________________
   SPF      X       X       X     X                    X
   _____________________________________________________________
   DLF      X       X       X             X
   _____________________________________________________________
   RNF      X       X       X             X      X
   _____________________________________________________________
   FNO      X
   _____________________________________________________________
   NOP      X
   _____________________________________________________________


                               Figure 3

                         Defined Command Fields

        Note: Command fields marked with an 'X' are defined.




J. White                                                       [Page 13]

RFC 122                Simple-Minded file System              April 1971


   0   ACCESS PASSWORD        The access password for this
       DEFAULTS               operation defaults to the access
                              or modification password which
                              appeared explicitly most
                              recently in the input stream;
                              hence, it does not appear
                              explicitly in the current
                              command.

   1   BIT COUNT DEFAULTS     The bit count for this operation
                              defaults to that which appeared
                              explicitly most recently in the
                              input stream; hence it does not
                              appear explicitly in the current
                              command.

   2   FILENAME DEFAULTS      The filename for this operation
                              defaults to the filename or new
                              filename which appeared explicitly
                              most recently in the input stream;
                              hence it does not appear
                              explicitly in the current command.

   3   ACCESS PASSWORD        The access password for this
       APPEARS EXPLICITLY     operation appears explicitly in
                              the current command. (Bits 0,
                              3 = 0 indicates that no access
                              password was/is-to-be defined
                              for the file.)

   4   ECHO OP CODE           SMFS shall echo the op code and
       AND FILENAME           filename (whether it appears
                              explicitly or not) by copying
                              them into the output stream
                              ahead of any other response to
                              the current command.

   5-7 undefined              Not examined; should be zeros.

   8   MODIFICATION           Same as Bit 0, but applied to
       PASSWORD DEFAULTS      the modification password, rather
                              than the access password.

                         Figure 4

              Definition of Command FLAGS Bits





J. White                                                       [Page 14]

RFC 122                Simple-Minded file System              April 1971


   9   FILE FORMATTED         FOR UDF/RTF: this segment is part
                              of a formatted file; hence SMFS
                              should record the bit count. For
                              RTF/SPF: the referenced file is
                              formatted; hence the bit count
                              does not appear explicitly in the
                              current command

   10   NEW FILENAME          same as Bit 2, but applied
        DEFAULTS              to the new filename, rather
                              than the filename.

   11   MODIFICATION PASSWORD Same as Bit 3, but applied to
        APPEARS EXPLICITLY    the modification password,
                              rather than the access
                              password.

   12-15 undefined            Not examined; should be zeros.

                      Figure 4(continued)

                 Definition of Command FLAGS Bits

      Note: The sixteen bits of FLAGS are numbered 0-15 from
         left to right.

   When a series of RTF/SPF operations referencing the same file are
   juxtaposed in the input stream (as discussed in Section V.D.), they
   cause successive segments of the file to be transmitted _only_ if
   both filename and access password default (Bits 0,2 = 1) (a null
   password is also acceptable) in those operations following the first
   in the series.  If the user specifies either parameter explicitly in
   a command in the series -- even if the explicitly stated value is the
   same as what would have been the default value -- SMFS considers the
   series terminated, as if a FNO had been encountered, and hence the
   command in question returns, or flushes, the first segment of the
   file.  Allowing both filename and password to default has the added
   effect, in both RTF/SPF and UDF series, of decreasing the processing
   time required by SMFS to execute the operations which comprise the
   series.  Under such circumstances, SMFS executes such initial
   functions as file location and password verification only once at the
   beginning of the series, rather than for each operation.  Hence, a
   potential for increased transmission rates exists.  Furthermore, in
   such a series of UDF/RPF operations, SMFS is able to conserve
   secondary storage by concatenating file segments before they are
   written out.





J. White                                                       [Page 15]

RFC 122                Simple-Minded file System              April 1971


   Whenever SMFS aborts the processing of a command in the input stream
   (e.g., the filename is invalid, an incorrect password is supplied,
   etc), SMFS flushes the entire command.  Suppose, for example, that
   the file specified in a UDF operation does not exist (i.e., has not
   been allocated).  If the data field for the operation is very long,
   SMFS may well detect the non-existence of the file before the data
   field has been transmitted by the user.  In such cases, SMFS will
   accept and flush whatever remains of the aborted command (in this
   case, including the very long data field) until it reaches the point
   in the input stream at which it expects to find the next command,
   which it will process normally.  SMFS will, however, notify the user
   that the command was aborted by placing an appropriate indicator in
   the output stream, and it will do this as soon as it detects the
   error (and hence, in this case, before the erroneous command has been
   flushed from the input stream).  Hence, the user has the option of
   aborting the process by closing the connection.

   SMFS considers a command with an invalid op code as an especially
   severe error, since it has no way of locating the start of the next
   command.  Accordingly, it places a special character (X'FF') in the
   output stream, follows it with the invalid op code, and then closes
   its connections to the user.

VII.  Output Stream Format

   SMFS will respond to each command it extracts from the input stream
   -- every command except FNO and NOP -- by placing a command response
   in the output stream.  Command responses have the following general
   format:

       8                8       32
     _________//___________________________//____
    | OP  |          | CMPL |         |          |
    |CODE | FILENAME | CODE |BIT COUNT|  DATA    |
    |_____|___//_____|______|_________|____//____|

   where the lengths of fixed-length fields have been indicated in bits.
   The field 'FILENAME' is further divided into the following subfields:

        8         8*LENGTH
     _______________//______
    |        |              |
    | LENGTH | FILENAME     |
    |________|______//______|

   where the 'LENGTH' subfield contains the length in 8-bit characters
   of the 'FILENAME' subfield.




J. White                                                       [Page 16]

RFC 122                Simple-Minded file System              April 1971


   This is the general format for SMFS command responses.  For responses
   to particular commands, not all fields may be present.  A particular
   subset of these fields is defined for each type of command response;
   no other fields will appear.  The defined fields for each command
   response type are indicated in Figure 5.

   The fields 'OP CODE' and 'FILENAME' are the op code and filename
   extracted by SMFS from the input stream and are echoed by SMFS in the
   output stream.  The filename is always echoed explicitly, even if it
   appeared implicitly in the input stream. 'OP CODE' and 'FILENAME' are
   suppressed and hence do not appear in the command response it Bit 4
   of the 'FLAGS' field of the corresponding command is set to 0.

   'CMPL CODE' contains an indication of the outcome of the operation.
   If the operation was completed successfully, 'CMPL CODE' contains a
   value equal to the op code of the command executed.  Hence, if
   echoing of 'OP CODE' and 'FILENAME' is not suppressed, the operation
   was successful if and only if 'OP CODE' and 'CMPL CODE' are
   identical.  If the operation as unsuccessful, 'CMPL CODE' contains an
   indication of the error encountered by SMFS in processing the
   command.  Completion codes are summarized in Figure 6.






























J. White                                                       [Page 17]

RFC 122                Simple-Minded file System              April 1971


                              C
                              O
                              M
                              P
                              L
                              E
                    F         T         B
                    I         I         I
          O         L         O         T
          P         E         N
                                        C
          C         N         C         O         D
          O         A         O         U         A
          D         M         D         N         T
          E         E         E         T         A
   _____________________________________________________

   NOP
   _____________________________________________________

   FNO
   _____________________________________________________

   ALF    X         X         X
   _____________________________________________________

   UDF    X         X         X
   _____________________________________________________

   RPF    X         X         X
   _____________________________________________________

   RTF    X         X         X         X         X
   _____________________________________________________

   SPF    X         X         X         X
   _____________________________________________________

   DLF    X         X         X
   _____________________________________________________

   RNF    X         X         X
    _____________________________________________________

                        Figure 5
             Defined Command Response Fields

   Note: Command response fields marked with an 'X' are defined.



J. White                                                       [Page 18]

RFC 122                Simple-Minded file System              April 1971


   An invalid op code in the input stream constitutes a special type of
   error.  SMFS's response is as follows.  A special command response is
   constructed.  It consists of the value X'FF' in an eight-bit field,
   followed by the erroneous op code, also in an eight-bit field.  The
   command response is placed in the output stream and connections to
   the user are closed.


      2  ALLOCATION SUCCESSFUL   The file was successfully allocated.

      3  UPDATE SUCCESSFUL       The file was successfully updated.

      4  REPLACE SUCCESSFUL      The file was successfully replaced.

      5  RETRIEVE SUCCESSFUL     The file segment was successfully
                                 retrieved.

      6  SPACE SUCCESSFUL        The file segment was successfully
                                 flushed.

      7  DELETION SUCCESSFUL     The file was successfully deleted.

      8  RENAME SUCCESSFUL       The file was successfully renamed.

     20  NO DEFAULT FILENAME     The user attempted to default the
                                 filename (or new filename), and the
                                 filename accumulator was empty.

     21  ZERO-LENGTH FILENAME    The length of the filename (or new
                                 filename) was specified as zero.

     22  FILENAME TOO LONG       The length of the filename (or new
                                 filename) exceeded 36 characters.

     23  INVALID FILENAME        The filename (or new filename)
                                 contained character(s) that do not
                                 appear in the character set.

     24  NO DEFAULT PASSWORD     The user attempted to default either
                                 the access or modification password,
                                 and the password accumulator was empty.

     25  ZERO-LENGTH PASSWORD    The length of either the access of
                                 modification password was specified as
                                 zero.

                                Figure 6
                            Completion Codes



J. White                                                       [Page 19]

RFC 122                Simple-Minded file System              April 1971


     26  PASSWORD TOO LONG       The length of either the access or
                                 modification password exceeded 36
                                 characters.

     27  NO DEFAULT BIT COUNT    The user attempted to default the bit
                                 count, and the bit-count accumulator
                                 was empty.

     28  INVALID PASSWORD        Either the access or modification
                                 password contained character(s) that do
                                 not appear in the character set.

     29  DUPLICATE FILENAME      Either the filename (in an ALF
                                 operation) or new filename (in a RNF
                                 operation) is already assigned to
                                 another file.

     30  INSUFFICIENT SPACE      (In an ALF operation) The requested
                                 amount of secondary storage is
                                 unavailable.

     31  ALLOCATION I/O ERROR    (In an ALF operation) An irrecoverable
                                 I/O error was encountered by SMFS while
                                 attempting to allocate the file.

     32  FILE NOT FOUND          The referenced file does not exist.

     33  SEARCH I/O ERROR        An irrecoverable I/O error was
                                 encountered by SMFS while attempting to
                                 locate the referenced file.

     34  FILE FULL               (In a UDF/RPF operation) The secondary
                                 storage allocated to the file has been
                                 exhausted.

     35  INCORRECT PASSWORD      The access or modification password
                                 supplied by the user does not match
                                 that declared when the file was
                                 allocated.

     36  FILE SIZE TOO SMALL     (In an ALF operation) The bit count
                                 specified is less than the minimum file
                                 size accepted by SMFS.

                          Figure 6 (continued)
                            Completion Codes





J. White                                                       [Page 20]

RFC 122                Simple-Minded file System              April 1971


     37  FILE SIZE TOO BIG       (In an ALF operation) The bit count
                                 specified exceeded the maximum file
                                 size accepted by SMFS.

     38  WRITE I/O ERROR         An irrecoverable I/O error as
                                 encountered by SMFS. (In an ALF
                                 operation) SMFS was attempting to
                                 record password information, or (in a
                                 UDF/RPF operation) SMFS as attempting
                                 to add data to the file.

     39  READ I/O ERROR          An irrecoverable I/O error was
                                 encountered by SMFS attempting to
                                 retrieve either password information or
                                 data.

     40  RENAME I/O ERROR        An irrecoverable I/O error was
                                 encountered by SMFS while attempting to
                                 rename the file.

     41  DELETE I/O ERROR        (In a DLF operation) An irrecoverable
                                 I/O error was encountered by SMFS while
                                 attempting to delete the file.

     42  END-OF-DATA             (In a RTF/SPR operation) The end of the
                                 file was reached before the requested
                                 segment had been transmitted/flushed.

                           Figure 6 (continued)
                             Completion Codes




         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Gottfried Janik 2/98 ]















J. White                                                       [Page 21]