doc: Add RFC documents

1 files changed, 218 insertions, 0 deletions

diff --git a/doc/rfc/rfc180.txt b/doc/rfc/rfc180.txt
new file mode 100644
index 0000000..23c48d9
--- /dev/null
+++ b/doc/rfc/rfc180.txt
@@ -0,0 +1,218 @@
+
+
+
+
+
+
+Network Working Group                                     Alex McKenzie
+Request for Comments #180                                 BBN
+NIC #7123                                                 25 June 1971
+Categories: D.7, G.3
+Updates: none
+Obsoletes: none
+
+                       File System Questionnaire
+
+As noted in RFC #164 (page 35), a subcommittee of the NWG, under the
+chairmanship of Abhay Bhushan, is currently generating proposals for a
+"data transfer protocol" and a "file transfer protocol".
+
+The subcommittee has decided that the file transfer protocol should
+provide standard methods for requesting the transfer of a file but
+should not, at this time, attempt to standardize file naming
+conventions, access control conventions, and the like.  Thus a user
+who is, for example, trying to store a file on a remote Host will be
+required to use the file naming conventions appropriate to the remote
+Host.
+
+Given the above point of view, it becomes imperative for users to have
+some source of information about Host file conventions.  Such
+information, once compiled, will also serve as input to possible
+standardization efforts of the file transfer subcommittee.  For this
+reason Abhay has asked me to solicit information on file conventions
+from the Host organizations.  What follows is a description of the
+kinds of information of interest.  I am well aware of the fact that
+many of you are tired of writing system descriptions; Xerox copies of
+short sections of your local documentation are fine if the result is
+complete and comprehensible.  (In the case that your Host will never
+permit network use of your file system, a note to that effect would be
+sufficient.)
+
+                         Information Requested
+
+1.  File naming conventions - We (loosely) define a pathname to be
+    the data string which must be input to the file system by a user
+    (a network user if your system makes a distinction between local
+    and network users) in order to identify a file.  We are interested
+    in syntax, semantics, and defaults.  Typical components of pathnames
+    are:
+
+         - "device" fields
+         - user names
+         - version numbers
+         - index names
+         - punctuation marks
+
+
+
+                                                                [Page 1]
+
+Common types of defaults are:
+
+         - device is disk
+         - version number is largest in system
+
+    For hierarchical file structures, descriptions may be fairly
+    complex, but with lots of defaults; in such cases an illustration
+    of a "normal" pathname might be helpful.
+
+2.  Access control mechanisms - Access control mechanisms range from
+    simply knowledge of a file's pathname to elaborate hierarchies
+    of group-project-task-username membership with passwords and
+    separate controls for reading and writing.  There are two
+    aspects of the access control mechanism which are of interest:
+
+    a.  A description of what inputs the user should give the file
+        system, both at the time of file creation and at the time of
+        retrieval, in order to define the permitted modes of access
+        and to gain access.  What are the syntax and semantics of
+        these inputs?
+
+    b.  A description of the ways in which the access control
+        mechanism is designed to help (or hinder) the sharing of
+        files.  For example, may two users "simultaniously" update a
+        given file?  May the creator of the file define a set of
+        authorized users to the file system (and how)?  Is it possible
+        to define different access controls for various subunits of a
+        given file?
+
+3.  Directories - Many systems maintain file directories which are
+    designed to be helpful to the user.  A directory might, for
+    example, provide a list of all files created by a particular
+    individual, along with some information regarding file size,
+    file structure, access controls, etc.  In general, such systems
+    allow the user to input a pathname and retrieve the directory to
+    which that pathname refers.  Aspects of the directory structure of
+    interest are:
+
+    a.  What are the syntax and semantics of a directory pathname?
+
+    b.  What use is a directory, i.e., what type of information
+        does the directory contain?
+
+    c.  What access controls are used for access to the directories?
+        For example, must a user supply a password in order to
+        retrieve a directory, and is this password typically the same
+        as the password he would use to retrieve a file listed in that
+        directory.
+
+
+
+                                                                [Page 2]
+
+4.  Commands and functions of the file system - A general description
+    of what the file system is designed to do would be useful.  For
+    example, the system might simply accept an entire file and store
+    it sequentially on a tape; with the only mode of retrieval being
+    to retrieve the entire file.  On the other hand, the system might
+    provide the ability to access any "subfield" with a unique
+    pathname.  Perhaps there is the ability to restructure a file,
+    change the access control, delete all the fields associated with a
+    directory, etc.  We realize that this aspect of the file system
+    begins to overlap the area of "data management", which is the
+    responsibility of another subcommittee; therefore, use your
+    judgement as to what functions are an intrinsic aspect of the
+    file-handling system and which are aspects of "data-management".
+
+5.  Internal representation and I/O modes - The remote user of a file
+    system will normally be interested in internal representation of
+    data only insofar as that representation of data is reflected in
+    the I/O interface between the file system and the network.  For
+    example, if all of the file system's I/O is in 8-bit ASCII
+    characters, then the user is unlikely to care if they are stored
+    in ASCII, EBCDIC, or some other form.  However, if an alternate
+    transmission mode is available it may be useful; for example,
+    two PDP-10's, both of which store 5 characters and one "filler"
+    bit per word, might find it advantageous to transfer information
+    in this mode rather than converting between internal representation
+    and 8-bit ASCII for each character.  Other information on internal
+    representation which would be of interest to the user might
+    include (if applicable):
+
+         - range of numeric data permitted
+         - maximum text string lengths
+         - whether the user must indicate "record" boundaries on input
+         - what "logical structure" information the user may specify
+           for a new file, and what he must specify
+         - whether the user must specify the file size before beginning
+           input, and how he does it
+
+6.  Undoubtedly, there will be aspects of each file system which don't
+    fit neatly into the categories above, but which users will find
+    important or essantial in using the system.  These should be
+    identified and described if possible.
+
+    Please address responses to this questionnaire to:
+
+               Alex McKenzie
+               Bolt Beranek and Newman Inc.
+               50 Moulton Street
+               Cambridge, Massachusetts 02138
+
+
+
+                                                                [Page 3]
+
+If the questions above are confusing, don't hesitate to call me for
+clarification at (617) 491-1850 ext. 441.  I will issue another RFC
+summarizing the responses after I have received a significant number
+of them.
+
+
+       [ This RFC was put into machine readable form for entry ]
+         [ into the online RFC archives by Stefan Hinker 6/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+