RFC 180 UNKNOWN FILE TRANSFER · DATA MANAGEMENT

File system questionnaire

Survey of file system conventions across ARPANET sites.

On rfc-editor.org ↗
PUBLISHED
June 1971
AUTHORS
A.M. McKenzie
STREAM
Legacy
SUBCOMMITTEE CHAIR
Abhay Bhushan
QUESTIONNAIRE TOPICS
6 main categories
CONTACT
Alex McKenzie, BBN
RESPONSE FORMAT
Documentation excerpts accepted
DOI
10.17487/RFC0180

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
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

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.

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

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 ]

AI ELI5

On this page
PROBLEMEarly work on standardizing file transfer protocols revealed that ARPANET sites used completely different file naming, access control, and directory conventions. A standard protocol could not assume a universal file system model.
MECHANISMRFC 180 is a questionnaire asking each ARPANET site to document their file system's naming conventions, access controls, directory structure, command functions, data representation, and I/O modes. The responses would inform protocol design decisions.
PRAGMATIC DOCUMENTATION APPROACHRather than standardizing file naming across the network, the file transfer protocol would require users to know each remote site's local conventions, with NIC collecting and distributing documentation of those conventions.

§1The File Transfer Challenge

RFC 180 presents a questionnaire about file systems on ARPANET hosts. A subcommittee of the NWG, chaired by Abhay Bhushan, was drafting proposals for a data transfer protocol and a file transfer protocol. The subcommittee made a strategic decision: the file transfer protocol would support file transfer, but would not attempt to standardize file naming conventions, access control conventions, or other local file system practices.

This meant users would need to know and use each remote system's local file naming conventions and access procedures. To help users, comprehensive documentation of each site's file system was needed.

Instead of making all computers use the same file names, they decided each site could keep its own system. But they wanted a big list of how each site's system worked.

§2File System Information Requested

The questionnaire requested detailed information in six categories:

File naming conventions: The pathname syntax (the data string needed to identify a file), including typical components like device fields, user names, version numbers, index names, and punctuation. Default values like "device is disk" or "version number is the largest in system" were important to document.

Access control mechanisms: These ranged from simple knowledge of a pathname to elaborate hierarchies with passwords and separate read/write controls. Sites were asked to describe user inputs needed at file creation and retrieval, and the sharing implications (can two users update the same file simultaneously?).

Directories: Many systems maintained directories listing all files from a user or project, with file size and access control information. Sites were asked about directory syntax, contents, and access control.

Commands and functions: The RFC noted that some systems accepted whole files for sequential storage, while others allowed access to subfields with unique pathnames or provided restructuring and deletion functions.

Internal representation and I/O modes: Information about how data was encoded (ASCII, EBCDIC, or native word format) and whether alternate transmission modes would be useful (for example, a native mode for two PDP-10s that stored five characters plus one filler bit per word).

They asked: How do you name a file? How do you control who can see it? Do you organize files in folders? What can you do with files? How is data stored inside?

§3Documentation and Impact

Alex McKenzie of BBN was tasked with collecting responses from all ARPANET sites. Responses could include Xerox copies of short documentation sections if they were complete and comprehensible. The RFC included McKenzie's phone number for clarification: (617) 491-1850 ext. 441.

The collected information served dual purposes: it immediately provided network users with the knowledge needed to use remote file systems, and it informed the file transfer subcommittee's standards work by documenting the diversity of actual practice across the network. This pragmatic approach recognized that standardizing file system behavior was infeasible in the short term, but standardizing the transfer mechanism for diverse file systems was achievable.

Each site sent back how their file system worked. Then the network could share that information so users knew what to expect, and it helped decide what the file transfer rules should be.

§4References