Movatterモバイル変換

Network Working Group                                     D. Crocker (UCLA-NMC)Request for Comments: 615                                                MAR 74NIC #21531Proposed NetworkStandard Data Pathname SyntaxThere seems to be an increasing call for a Network Standard Data Pathname(NSDP); that is, a standardized means of referring to a specific locationfor/of a collection of bits somewhere on the Network.The reasons for a standard or virtual anything have been discussed, atlength, elsewhere and will not be elaborated upon here. Rather thanattack the entire issue of virtual pathnames, I wish only to propose astandardized SYNTAX for specifying pathnames. Such a standard will beuseful for 1) users who are unfamiliar with a site or who use severaldifferent sites and do not want to have to remember each site'sidiosynchracies, 2) programs accessing data at several other sites, and3) 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-feedAnd 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 casein <name> fields:<Key> indicates what part of the pathname the next <name> is going torefer to: The single-character keys are abbreviations for the respectivefull-word keys:<Fields> ARE order dependent, but defaulted ones may be omitted. Theorder 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, andnothing 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 followingdefaults 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 CommentsThe only field that must be considered in relation to any host's currentsyntax is the escape-to-NVP field (The per-cent sign as the firstcharacter of a pathname specification): It is not currently known toconflict 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 wouldcause minor problems at Multics; but more importantly as a graphic, it istoo similar to the numeral "1":The syntax is intended to be adequate for all hosts, so any given portionof it may be inappropriate for any given host.A site is expected to permit specifications in a given field iff thatsite already has a way of accepting the same information:I believe that any modifications to the syntax will be gracefuladditions, rather than wholesale redesign, and thus can be deferred for awhile. Currently, any undefined attributes must be specified in aSiteparm field:Perhaps Version, Access protection and Accounting, as well as other typesof information, should be made standard <key>s, rather than buried asSiteparms. I expect that the next version of the NSDP Syntaxspecification will include them as <key>s, but I would like to wait forsome comments from the community.The syntax does not currently allow addressing any collection of bitssmaller 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:DisclaimerA pathname specified in the proposed syntax is fairly easy to type but isquite ugly to read: So, at the expense of design cleanliness, the<L-delim>/<R-delim> syntax was modified in an attempt to remedy theproblem 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 andMultics conventions: That is,       (Network)[Host]Peripheral:Directory>Filename:Type;SiteparmThough visually more attractive and generally quicker to type, it lacksextensibility. For example, adding Version number or Access protection asstandard fields would be difficult:It is suggested that human interfaces be built to translate to/from NSDPsyntax and the user's standard environment.                                -4-

Some sample pathnames:%H[ISI]D<DCROCKER>F(MESSAGE)T/TXT/S(P77O4O4)<cr><lf> refers to myprotected message file at ISI (<DCROCKER>MESSAGE:TXT;P77O4O4).%H/OFFICE-l/D>JOURNAL>F<l8659>T.NLS.<cr><lf> refers to NIC Journaldocument #18659 (Tenex file <JOURNAL>l8659:NLS):%H/65/D.ARP061.D.LAD:F.DOCUMENT.<cr><lf> refers to a fileARPO6l:LAD.DOCUMENT at UCLA-CCN. Note the use of multiple Directoryfields.%H[540]D//D>udd>D>Comp=net>D>Map>F(Mail)<cr><lf> refers to fileCompNet>Map>Mail at Mit-Multics. Note that the initial NSPD Directory<name> field is empty. This conforms to Multics' method of starting atthe 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-