home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0180.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  7.7 KB  |  219 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     Alex McKenzie
  8. Request for Comments #180                                 BBN
  9. NIC #7123                                                 25 June 1971
  10. Categories: D.7, G.3
  11. Updates: none
  12. Obsoletes: none
  13.  
  14.                        File System Questionnaire
  15.  
  16. As noted in RFC #164 (page 35), a subcommittee of the NWG, under the
  17. chairmanship of Abhay Bhushan, is currently generating proposals for a
  18. "data transfer protocol" and a "file transfer protocol".
  19.  
  20. The subcommittee has decided that the file transfer protocol should
  21. provide standard methods for requesting the transfer of a file but
  22. should not, at this time, attempt to standardize file naming
  23. conventions, access control conventions, and the like.  Thus a user
  24. who is, for example, trying to store a file on a remote Host will be
  25. required to use the file naming conventions appropriate to the remote
  26. Host.
  27.  
  28. Given the above point of view, it becomes imperative for users to have
  29. some source of information about Host file conventions.  Such
  30. information, once compiled, will also serve as input to possible
  31. standardization efforts of the file transfer subcommittee.  For this
  32. reason Abhay has asked me to solicit information on file conventions
  33. from the Host organizations.  What follows is a description of the
  34. kinds of information of interest.  I am well aware of the fact that
  35. many of you are tired of writing system descriptions; Xerox copies of
  36. short sections of your local documentation are fine if the result is
  37. complete and comprehensible.  (In the case that your Host will never
  38. permit network use of your file system, a note to that effect would be
  39. sufficient.)
  40.  
  41.                          Information Requested
  42.  
  43. 1.  File naming conventions - We (loosely) define a pathname to be
  44.     the data string which must be input to the file system by a user
  45.     (a network user if your system makes a distinction between local
  46.     and network users) in order to identify a file.  We are interested
  47.     in syntax, semantics, and defaults.  Typical components of pathnames
  48.     are:
  49.  
  50.          - "device" fields
  51.          - user names
  52.          - version numbers
  53.          - index names
  54.          - punctuation marks
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. Common types of defaults are:
  61.  
  62.          - device is disk
  63.          - version number is largest in system
  64.  
  65.     For hierarchical file structures, descriptions may be fairly
  66.     complex, but with lots of defaults; in such cases an illustration
  67.     of a "normal" pathname might be helpful.
  68.  
  69. 2.  Access control mechanisms - Access control mechanisms range from
  70.     simply knowledge of a file's pathname to elaborate hierarchies
  71.     of group-project-task-username membership with passwords and
  72.     separate controls for reading and writing.  There are two
  73.     aspects of the access control mechanism which are of interest:
  74.  
  75.     a.  A description of what inputs the user should give the file
  76.         system, both at the time of file creation and at the time of
  77.         retrieval, in order to define the permitted modes of access
  78.         and to gain access.  What are the syntax and semantics of
  79.         these inputs?
  80.  
  81.     b.  A description of the ways in which the access control
  82.         mechanism is designed to help (or hinder) the sharing of
  83.         files.  For example, may two users "simultaniously" update a
  84.         given file?  May the creator of the file define a set of
  85.         authorized users to the file system (and how)?  Is it possible
  86.         to define different access controls for various subunits of a
  87.         given file?
  88.  
  89. 3.  Directories - Many systems maintain file directories which are
  90.     designed to be helpful to the user.  A directory might, for
  91.     example, provide a list of all files created by a particular
  92.     individual, along with some information regarding file size,
  93.     file structure, access controls, etc.  In general, such systems
  94.     allow the user to input a pathname and retrieve the directory to
  95.     which that pathname refers.  Aspects of the directory structure of
  96.     interest are:
  97.  
  98.     a.  What are the syntax and semantics of a directory pathname?
  99.  
  100.     b.  What use is a directory, i.e., what type of information
  101.         does the directory contain?
  102.  
  103.     c.  What access controls are used for access to the directories?
  104.         For example, must a user supply a password in order to
  105.         retrieve a directory, and is this password typically the same
  106.         as the password he would use to retrieve a file listed in that
  107.         directory.
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. 4.  Commands and functions of the file system - A general description
  114.     of what the file system is designed to do would be useful.  For
  115.     example, the system might simply accept an entire file and store
  116.     it sequentially on a tape; with the only mode of retrieval being
  117.     to retrieve the entire file.  On the other hand, the system might
  118.     provide the ability to access any "subfield" with a unique
  119.     pathname.  Perhaps there is the ability to restructure a file,
  120.     change the access control, delete all the fields associated with a
  121.     directory, etc.  We realize that this aspect of the file system
  122.     begins to overlap the area of "data management", which is the
  123.     responsibility of another subcommittee; therefore, use your
  124.     judgement as to what functions are an intrinsic aspect of the
  125.     file-handling system and which are aspects of "data-management".
  126.  
  127. 5.  Internal representation and I/O modes - The remote user of a file
  128.     system will normally be interested in internal representation of
  129.     data only insofar as that representation of data is reflected in
  130.     the I/O interface between the file system and the network.  For
  131.     example, if all of the file system's I/O is in 8-bit ASCII
  132.     characters, then the user is unlikely to care if they are stored
  133.     in ASCII, EBCDIC, or some other form.  However, if an alternate
  134.     transmission mode is available it may be useful; for example,
  135.     two PDP-10's, both of which store 5 characters and one "filler"
  136.     bit per word, might find it advantageous to transfer information
  137.     in this mode rather than converting between internal representation
  138.     and 8-bit ASCII for each character.  Other information on internal
  139.     representation which would be of interest to the user might
  140.     include (if applicable):
  141.  
  142.          - range of numeric data permitted
  143.          - maximum text string lengths
  144.          - whether the user must indicate "record" boundaries on input
  145.          - what "logical structure" information the user may specify
  146.            for a new file, and what he must specify
  147.          - whether the user must specify the file size before beginning
  148.            input, and how he does it
  149.  
  150. 6.  Undoubtedly, there will be aspects of each file system which don't
  151.     fit neatly into the categories above, but which users will find
  152.     important or essantial in using the system.  These should be
  153.     identified and described if possible.
  154.  
  155.     Please address responses to this questionnaire to:
  156.  
  157.                Alex McKenzie
  158.                Bolt Beranek and Newman Inc.
  159.                50 Moulton Street
  160.                Cambridge, Massachusetts 02138
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. If the questions above are confusing, don't hesitate to call me for
  167. clarification at (617) 491-1850 ext. 441.  I will issue another RFC
  168. summarizing the responses after I have received a significant number
  169. of them.
  170.  
  171.  
  172.        [ This RFC was put into machine readable form for entry ]
  173.          [ into the online RFC archives by Stefan Hinker 6/97 ]
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219.