summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc180.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc180.txt')
-rw-r--r--doc/rfc/rfc180.txt218
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]
+