home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc615 < prev    next >
Text File  |  1991-04-21  |  9KB  |  288 lines
  1. Network Working Group                                     D. Crocker (UCLA-NMC)
  2. Request for Comments: 615                                                MAR 74
  3. NIC #21531
  4.  
  5.                            Proposed Network
  6.                      Standard Data Pathname Syntax
  7.  
  8. There seems to be an increasing call for a Network Standard Data Pathname
  9. (NSDP); that is, a standardized means of referring to a specific location
  10. for/of a collection of bits somewhere on the Network.
  11.  
  12. The reasons for a standard or virtual anything have been discussed, at
  13. length, elsewhere and will not be elaborated upon here. Rather than
  14. attack the entire issue of virtual pathnames, I wish only to propose a
  15. standardized SYNTAX for specifying pathnames. Such a standard will be
  16. useful for 1) users who are unfamiliar with a site or who use several
  17. different sites and do not want to have to remember each site's
  18. idiosynchracies, 2) programs accessing data at several other sites, and
  19. 3) documentation:
  20.  
  21. The syntax allows the user to specify the necessary network, host,
  22. peripheral device, directory, file, type, and site-specific fields.
  23. Adding other fields, as needed, is expected to be quite simple.
  24.  
  25. First the BNF:
  26.  
  27.    <NSDP> ::= % <bulk> <cr><lf>
  28.  
  29.    <bulk> ::= <field> / <field> <bulk>
  30.  
  31.    <field> ::= <key> <L-delim> <name> <R-delim>
  32.  
  33.    <key> ::= NETWORK / HOST / PERIPHERAL/ DIRECTORY /
  34.              FILE / TYPE / SITEPARM / N / H / P / D / F /
  35.              T / S
  36.  
  37. <L-delim> ::= any printable character that is not in the
  38.               succeeding <name> field and that is
  39.               acceptable to the object site: For visual
  40.               aesthetics and to facilitate human parsing,
  41.               anytime <L-delim> is a left-bracket
  42.               character (<, [, (, _), <R-delim> must be
  43.               the complementary right-bracket character
  44.               (>, ], ), |).
  45.  
  46. <name> ::=    any sequence of characters acceptable to the
  47.               object site. This is the actual data field
  48.               with the file, directory, device (or
  49.               whatever) name.
  50.  
  51. <R-delim> ::= Either 1) the same character as <L-delim> or
  52.               2) if the <L-delim> character is a
  53.               left-bracket character (<, [, (, _) then its
  54.               complementary right-bracket (>, ], ), |).
  55.  
  56.  
  57.                                  -1-
  58. <cr> ::=      carriage-return
  59.  
  60. <lf> ::=      line-feed
  61.  
  62. And some elaboration:
  63.  
  64. The syntax allows <name> fields to be an arbitrary number of rs long.
  65. Case is irrelevant to the syntax, though some sites will care about case
  66. in <name> fields:
  67.  
  68. <Key> indicates what part of the pathname the next <name> is going to
  69. refer to: The single-character keys are abbreviations for the respective
  70. full-word keys:
  71.  
  72. <Fields> ARE order dependent, but defaulted ones may be omitted. The
  73. order is as indicated for <key>s: That is, Network, Host, ..: Siteparm:
  74.  
  75. Fields may be repeated, as appropriate for the object site; that is,
  76. multiple Directory fields, etc:
  77.  
  78. The validity of any combination of <field>s is entirely site-dependent:
  79. For example, if a site will accept it, an NSDP with a Host field, and
  80. nothing more, is permissible:
  81.  
  82. <delim> is used to delimit the beginning and end of the <name> field:
  83.  
  84. Explanation of <key>s:
  85.  
  86.        NETWORK or N:   Currently, only ARPA is defined.
  87.  
  88.        HOST or H:      Reference to host, by official name or
  89.                        nickname or number: The default radix is
  90.                        ten; a numeric string ending with "H"
  91.                        indicates hexadecimal, "O"(oh) indicates
  92.                        octal, and (gratuitously) "D" indicates
  93.                        decimal:
  94.  
  95.       PERIPHERAL or P: Peripheral device being referred to:
  96.  
  97.       DIRECTORY or D:  Name of a directory which contains a
  98.                        pointer to the entity (directory or
  99.                        filename) specified in the following
  100.                        <field>:
  101.  
  102.       FILE or F:       Basic name of the file or data set:
  103.  
  104.       TYPE or T:       Optional modifier to filename: (Tenex
  105.                        calls it the extension.)
  106.  
  107.       SITEPARM or S:   A parameter, such as an access
  108.                        specification or version number, peculiar
  109.                        to the object site. The content of the
  110.                        <name> field must serve to identify what
  111.                        Siteparm is involved. Each site will be
  112.                        responsible for defining the syntax of
  113.                        Siteparm <name>s it will accept.
  114.  
  115.                                    -2-
  116. Some reserved PERIPHERAL <name>s:
  117.  
  118.       DISK or DSK:     Immediately accessible, direct-access
  119.                        storage.
  120.  
  121.       ONLINE or ONL:    Whatever immediately-accessible (measured
  122.                         in fractions of a second) storage the
  123.                         user accesses by default; usually disk:
  124.  
  125.       TAPE or TAP:      Industry-compatible magnetic tape:
  126.  
  127.       TAPE7 or TP7:     7-Track industry compatible tape:
  128.  
  129.       TAPE9 or TP9:     9-Track industry compatible tape:
  130.  
  131.       DECTAPE or DEC:   DEC Tape.
  132.  
  133.       OFFLINE or OFF:   Any tertiary storage; usually tape,
  134.                         though "devices" like the Datacomputer
  135.                         are permissible: The user should expect
  136.                         to wait minutes or hours before being
  137.                         able to access OFFLINE files:
  138.  
  139.       PRINTER or PTR:   Any available line-printer:
  140.  
  141.       DOCPRINTER or DOC:Upper-lower case line printer, preferably
  142.                         with 8 1/2" X 11" unlined paper.
  143.  
  144.       PAPER or PAP:     Paper tape.
  145.  
  146.       PUNCH or PUN:     Standard 8O-column card punch.
  147.  
  148.       READER or RDR:    Standard 80-column card reader:
  149.  
  150.       OPERATOR or OPR:  System Operator's console.
  151.  
  152.       CONSULTANT or CON: On-line consultant.
  153.  
  154. Defaults:
  155.  
  156. Defaults will generally be context dependent. Consequently, the following
  157. defaults are offered only as guidelines:
  158.  
  159.       Network:    ARPA
  160.  
  161.       Host:       The host interpreting the NVP
  162.  
  163.       Peripheral: ONLINE (DISK)
  164.  
  165.       Directory:  The user's current "working" directory,
  166.                   usually set by the logon process:
  167.  
  168.       Filename:    None.
  169.  
  170.       Type:        None.
  171.  
  172.       Siteparm:     None.
  173.  
  174.                                    -3-
  175.  
  176. General Comments
  177.  
  178. The only field that must be considered in relation to any host's current
  179. syntax is the escape-to-NVP field (The per-cent sign as the first
  180. character of a pathname specification): It is not currently known to
  181. conflict with any host's syntax:
  182.  
  183. Exclamation mark (!) is the only other character that seems permissible
  184. (on the assumption that the character should be a graphic): Its use would
  185. cause minor problems at Multics; but more importantly as a graphic, it is
  186. too similar to the numeral "1":
  187.  
  188. The syntax is intended to be adequate for all hosts, so any given portion
  189. of it may be inappropriate for any given host.
  190.  
  191. A site is expected to permit specifications in a given field iff that
  192. site already has a way of accepting the same information:
  193.  
  194. I believe that any modifications to the syntax will be graceful
  195. additions, rather than wholesale redesign, and thus can be deferred for a
  196. while. Currently, any undefined attributes must be specified in a
  197. Siteparm field:
  198.  
  199. Perhaps Version, Access protection and Accounting, as well as other types
  200. of information, should be made standard <key>s, rather than buried as
  201. Siteparms. I expect that the next version of the NSDP Syntax
  202. specification will include them as <key>s, but I would like to wait for
  203. some comments from the community.
  204.  
  205. The syntax does not currently allow addressing any collection of bits
  206. smaller than a file: This can be remedied by adding PAGE, BYTE and other
  207. <key>s; but, again, I would like to solicit some comments first:
  208.  
  209.  
  210. Disclaimer
  211.  
  212. A pathname specified in the proposed syntax is fairly easy to type but is
  213. quite ugly to read: So, at the expense of design cleanliness, the
  214. <L-delim>/<R-delim> syntax was modified in an attempt to remedy the
  215. problem somewhat: As you will see below, it is only partially successful.
  216.  
  217. The first draft of this document had a syntax that was a mix of Tenex and
  218. Multics conventions: That is,
  219.  
  220.        (Network)[Host]Peripheral:Directory>Filename:Type;Siteparm
  221.  
  222. Though visually more attractive and generally quicker to type, it lacks
  223. extensibility. For example, adding Version number or Access protection as
  224. standard fields would be difficult:
  225.  
  226. It is suggested that human interfaces be built to translate to/from NSDP
  227. syntax and the user's standard environment.
  228.  
  229.  
  230.                                 -4-
  231.  
  232. Some sample pathnames:
  233.  
  234.  
  235. %H[ISI]D<DCROCKER>F(MESSAGE)T/TXT/S(P77O4O4)<cr><lf> refers to my
  236. protected message file at ISI (<DCROCKER>MESSAGE:TXT;P77O4O4).
  237.  
  238. %H/OFFICE-l/D>JOURNAL>F<l8659>T.NLS.<cr><lf> refers to NIC Journal
  239. document #18659 (Tenex file <JOURNAL>l8659:NLS):
  240.  
  241. %H/65/D.ARP061.D.LAD:F.DOCUMENT.<cr><lf> refers to a file
  242. ARPO6l:LAD.DOCUMENT at UCLA-CCN. Note the use of multiple Directory
  243. fields.
  244.  
  245. %H[540]D//D>udd>D>Comp=net>D>Map>F(Mail)<cr><lf> refers to file
  246. CompNet>Map>Mail at Mit-Multics. Note that the initial NSPD Directory
  247. <name> field is empty. This conforms to Multics' method of starting at
  248. the top of its directory structure:
  249.  
  250. I would like to thank Jon Postel, Vint Cerf, Jim White, Charlie Kline,
  251. Ken Pogran, Jerry Burchfiel and Tom Boynton for their suggestions.
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.                                  -5-