The RFC Archive
 The RFC Archive   RFC 615   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 615

Proposed Network Standard Data Pathname syntax

Last modified on Thursday, October 15th, 1992

Permanent link to RFC 615
Search GitHub Wiki for RFC 615
Show other RFCs mentioning 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-
Proposed Network Standard Data Pathname syntax

RFC TOTAL SIZE: 9448 bytes
PUBLICATION DATE: Thursday, October 15th, 1992
LEGAL RIGHTS: The IETF Trust (see BCP 78)      


RFC-ARCHIVE.ORG

© RFC 615: The IETF Trust, Thursday, October 15th, 1992
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement