doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc122.txt b/doc/rfc/rfc122.txt
new file mode 100644
index 0000000..0dacf14
--- /dev/null
+++ b/doc/rfc/rfc122.txt
@@ -0,0 +1,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]
+