RFC 180

File System Questionnaire 💾✨

Okay bestie, here's the tea 🫶. This is RFC #180, which lives in the Network Working Group (the NWG) and is also filed as NIC #7123. Alex McKenzie at BBN wrote it on 25 June 1971. It's filed under categories D.7 and G.3, it updates nothing, and it obsoletes nothing, so it's totally standalone 💅.

As noted in RFC #164 (page 35), there's a subcommittee of the NWG, chaired by Abhay Bhushan, cooking up proposals for a "data transfer protocol" and a "file transfer protocol" 🧚. The subcommittee has decided that the file transfer protocol should give everyone standard ways to request a file transfer, but it should not, for now, try to standardize file naming conventions, access control conventions, and stuff like that 🙈. So if you're trying to store a file on a remote Host, you will be required to use that remote Host's own naming conventions.

Given that, users absolutely need some source of info about Host file conventions 😭. Once it's compiled, that info also feeds into whatever the file transfer subcommittee ends up standardizing, which is why Abhay asked me to collect it from the Host organizations. Below is the kind of info I'm after. I know many of you are so over writing system descriptions 🥱, so photocopies of short sections of your local docs are totally fine as long as the result is complete and comprehensible. (If your Host will never allow network use of your file system, a note saying so is enough.)

Information Requested 📋

1. File naming conventions - We (loosely) define a pathname to be the data string that a user must input to the file system (a network user, if your system makes a distinction between local and network users) in order to identify a file. We're 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 get pretty complex but with lots of defaults 🌈. In those cases, an illustration of a "normal" pathname might be helpful.

2. Access control mechanisms - These range from simply knowing a file's pathname all the way up 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 that we're interested in:

a. A description of what inputs the user gives the file system, both at file creation and at retrieval, 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 the access control mechanism is designed to help (or hinder) file sharing. For example, may two users "simultaniously" update a given file? May the creator of a 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 designed to be helpful to the user 🍓. A directory might, for example, list all files created by a particular individual, along with info about file size, file structure, access controls, etc. In general, these systems let the user input a pathname and retrieve the directory that pathname refers to. The aspects of the directory structure we're interested in 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 directories? For example, must a user supply a password to retrieve a directory, and is that password typically the same as the password he'd 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 super useful 🧠. For example, the system might simply accept an entire file and store it sequentially on a tape, with the only way to retrieve it being to get the whole file back. On the other hand, the system might let you access any "subfield" with a unique pathname. Maybe you can restructure a file, change the access control, or delete all the fields associated with a directory, etc. We know this aspect starts to overlap with "data management," which is another subcommittee's responsibility, so use your judgement about which functions are intrinsic to the file-handling system and which belong to "data-management" 🦋.
5. Internal representation and I/O modes - The remote user of a file system will normally only care about internal representation insofar as it shows up 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, the user probably won't care whether the data is stored in ASCII, EBCDIC, or some other form. However, if an alternate transmission mode is available, it might be useful. Two PDP-10's, both storing 5 characters and one "filler" bit per word, might find it advantageous to transfer information in that mode instead of converting to and from 8-bit ASCII for every character ✨. Other info on internal representation that might interest the user includes (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 that don't fit neatly into the categories above but that users will find important or essential 🔥. Please identify and describe these 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'll issue another RFC summarizing the responses after I've 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 ]