Proposed Network Standard Data Pathname syntax
RFC 615
This RFC was published on the Legacy stream.
This RFC is not endorsed by the IETF and has no formal standing in the
IETF standards process.
Document | Type |
RFC
- Unknown
(March 1974)
Obsoleted by RFC 645
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
RFC stream | Legacy | ||
Formats | |||
IESG | Responsible AD | (None) | |
Send notices to | (None) |
RFC 615
Network Working Group D. Crocker (UCLA-NMC) Request for Comments: 615 MAR 74 NIC #21531 Proposed Network Standard Data Pathname Syntax There seems to be an increasing call for a Network Standard Data Pathname (NSDP); that is, a standardized means of referring to a specific location for/of a collection of bits somewhere on the Network. The reasons for a standard or virtual anything have been discussed, at length, elsewhere and will not be elaborated upon here. Rather than attack the entire issue of virtual pathnames, I wish only to propose a standardized SYNTAX for specifying pathnames. Such a standard will be useful for 1) users who are unfamiliar with a site or who use several different sites and do not want to have to remember each site's idiosynchracies, 2) programs accessing data at several other sites, and 3) documentation: The syntax allows the user to specify the necessary network, host, peripheral device, directory, file, type, and site-specific fields. Adding other fields, as needed, is expected to be quite simple. First the BNF: <NSDP> ::= % <bulk> <cr><lf> <bulk> ::= <field> / <field> <bulk> <field> ::= <key> <L-delim> <name> <R-delim> <key> ::= NETWORK / HOST / PERIPHERAL/ DIRECTORY / FILE / TYPE / SITEPARM / N / H / P / D / F / T / S <L-delim> ::= any printable character that is not in the succeeding <name> field and that is acceptable to the object site: For visual aesthetics and to facilitate human parsing, anytime <L-delim> is a left-bracket character (<, [, (, _), <R-delim> must be the complementary right-bracket character (>, ], ), |). <name> ::= any sequence of characters acceptable to the object site. This is the actual data field with the file, directory, device (or whatever) name. <R-delim> ::= Either 1) the same character as <L-delim> or 2) if the <L-delim> character is a left-bracket character (<, [, (, _) then its complementary right-bracket (>, ], ), |). -1- <cr> ::= carriage-return <lf> ::= line-feed And some elaboration: The syntax allows <name> fields to be an arbitrary number of rs long. Case is irrelevant to the syntax, though some sites will care about case in <name> fields: <Key> indicates what part of the pathname the next <name> is going to refer to: The single-character keys are abbreviations for the respective full-word keys: <Fields> ARE order dependent, but defaulted ones may be omitted. The order is as indicated for <key>s: That is, Network, Host, ..: Siteparm: Fields may be repeated, as appropriate for the object site; that is, multiple Directory fields, etc: The validity of any combination of <field>s is entirely site-dependent: For example, if a site will accept it, an NSDP with a Host field, and nothing more, is permissible: <delim> is used to delimit the beginning and end of the <name> field: Explanation of <key>s: NETWORK or N: Currently, only ARPA is defined. HOST or H: Reference to host, by official name or nickname or number: The default radix is ten; a numeric string ending with "H" indicates hexadecimal, "O"(oh) indicates octal, and (gratuitously) "D" indicates decimal: PERIPHERAL or P: Peripheral device being referred to: DIRECTORY or D: Name of a directory which contains a pointer to the entity (directory or filename) specified in the following <field>: FILE or F: Basic name of the file or data set: TYPE or T: Optional modifier to filename: (Tenex calls it the extension.) SITEPARM or S: A parameter, such as an access specification or version number, peculiar to the object site. The content of the <name> field must serve to identify what Siteparm is involved. Each site will be responsible for defining the syntax of Siteparm <name>s it will accept. -2- Some reserved PERIPHERAL <name>s: DISK or DSK: Immediately accessible, direct-access storage. ONLINE or ONL: Whatever immediately-accessible (measured in fractions of a second) storage the user accesses by default; usually disk: TAPE or TAP: Industry-compatible magnetic tape: TAPE7 or TP7: 7-Track industry compatible tape: TAPE9 or TP9: 9-Track industry compatible tape: DECTAPE or DEC: DEC Tape. OFFLINE or OFF: Any tertiary storage; usually tape, though "devices" like the Datacomputer are permissible: The user should expect to wait minutes or hours before being able to access OFFLINE files: PRINTER or PTR: Any available line-printer: DOCPRINTER or DOC:Upper-lower case line printer, preferably with 8 1/2" X 11" unlined paper. PAPER or PAP: Paper tape. PUNCH or PUN: Standard 8O-column card punch. READER or RDR: Standard 80-column card reader: OPERATOR or OPR: System Operator's console. CONSULTANT or CON: On-line consultant. Defaults: Defaults will generally be context dependent. Consequently, the following defaults are offered only as guidelines: Network: ARPA Host: The host interpreting the NVP Peripheral: ONLINE (DISK) Directory: The user's current "working" directory, usually set by the logon process: Filename: None. Type: None. Siteparm: None. -3- General Comments The only field that must be considered in relation to any host's current syntax is the escape-to-NVP field (The per-cent sign as the first character of a pathname specification): It is not currently known to conflict with any host's syntax: Exclamation mark (!) is the only other character that seems permissible (on the assumption that the character should be a graphic): Its use would cause minor problems at Multics; but more importantly as a graphic, it is too similar to the numeral "1": The syntax is intended to be adequate for all hosts, so any given portion of it may be inappropriate for any given host. A site is expected to permit specifications in a given field iff that site already has a way of accepting the same information: I believe that any modifications to the syntax will be graceful additions, rather than wholesale redesign, and thus can be deferred for a while. Currently, any undefined attributes must be specified in a Siteparm field: Perhaps Version, Access protection and Accounting, as well as other types of information, should be made standard <key>s, rather than buried as Siteparms. I expect that the next version of the NSDP Syntax specification will include them as <key>s, but I would like to wait for some comments from the community. The syntax does not currently allow addressing any collection of bits smaller than a file: This can be remedied by adding PAGE, BYTE and other <key>s; but, again, I would like to solicit some comments first: Disclaimer A pathname specified in the proposed syntax is fairly easy to type but is quite ugly to read: So, at the expense of design cleanliness, the <L-delim>/<R-delim> syntax was modified in an attempt to remedy the problem somewhat: As you will see below, it is only partially successful. The first draft of this document had a syntax that was a mix of Tenex and Multics conventions: That is, (Network)[Host]Peripheral:Directory>Filename:Type;Siteparm Though visually more attractive and generally quicker to type, it lacks extensibility. For example, adding Version number or Access protection as standard fields would be difficult: It is suggested that human interfaces be built to translate to/from NSDP syntax and the user's standard environment. -4- Some sample pathnames: %H[ISI]D<DCROCKER>F(MESSAGE)T/TXT/S(P77O4O4)<cr><lf> refers to my protected message file at ISI (<DCROCKER>MESSAGE:TXT;P77O4O4). %H/OFFICE-l/D>JOURNAL>F<l8659>T.NLS.<cr><lf> refers to NIC Journal document #18659 (Tenex file <JOURNAL>l8659:NLS): %H/65/D.ARP061.D.LAD:F.DOCUMENT.<cr><lf> refers to a file ARPO6l:LAD.DOCUMENT at UCLA-CCN. Note the use of multiple Directory fields. %H[540]D//D>udd>D>Comp=net>D>Map>F(Mail)<cr><lf> refers to file CompNet>Map>Mail at Mit-Multics. Note that the initial NSPD Directory <name> field is empty. This conforms to Multics' method of starting at the top of its directory structure: I would like to thank Jon Postel, Vint Cerf, Jim White, Charlie Kline, Ken Pogran, Jerry Burchfiel and Tom Boynton for their suggestions. -5-