RFC615 Proposed Network Standard Data Pathname syntax
0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT=9448 bytes) (Obsoleted by RFC0645) (Status: UNKNOWN)
日本語訳
RFC一覧
参照
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:
::= %
::= /
::=
::= NETWORK / HOST / PERIPHERAL/ DIRECTORY /
FILE / TYPE / SITEPARM / N / H / P / D / F /
T / S
::= any printable character that is not in the
succeeding field and that is
acceptable to the object site: For visual
aesthetics and to facilitate human parsing,
anytime is a left-bracket
character (<, [, (, _), must be
the complementary right-bracket character
(>, ], ), |).
::= any sequence of characters acceptable to the
object site. This is the actual data field
with the file, directory, device (or
whatever) name.
::= Either 1) the same character as or
2) if the character is a
left-bracket character (<, [, (, _) then its
complementary right-bracket (>, ], ), |).
-1-
::= carriage-return
::= line-feed
And some elaboration:
The syntax allows fields to be an arbitrary number of rs long.
Case is irrelevant to the syntax, though some sites will care about case
in fields:
indicates what part of the pathname the next is going to
refer to: The single-character keys are abbreviations for the respective
full-word keys:
ARE order dependent, but defaulted ones may be omitted. The
order is as indicated for 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 s is entirely site-dependent:
For example, if a site will accept it, an NSDP with a Host field, and
nothing more, is permissible:
is used to delimit the beginning and end of the field:
Explanation of 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
:
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
field must serve to identify what
Siteparm is involved. Each site will be
responsible for defining the syntax of
Siteparm s it will accept.
-2-
Some reserved PERIPHERAL 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 s, rather than buried as
Siteparms. I expect that the next version of the NSDP Syntax
specification will include them as 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
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
/ 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]DF(MESSAGE)T/TXT/S(P77O4O4) refers to my
protected message file at ISI (MESSAGE:TXT;P77O4O4).
%H/OFFICE-l/D>JOURNAL>FT.NLS. refers to NIC Journal
document #18659 (Tenex file l8659:NLS):
%H/65/D.ARP061.D.LAD:F.DOCUMENT. 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) refers to file
CompNet>Map>Mail at Mit-Multics. Note that the initial NSPD Directory
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.
一覧
スポンサーリンク
