As per Relevance of the word specific, we have this rfc below:
Network Working Group D. Crocker (UCLA-NMC
Request for Comments: 615 MAR 74
NIC #21531
Proposed
Standard Data Pathname
There seems to be an increasing call for a Network Standard Data
(NSDP); that is, a standardized means of referring to a specific
for/of a collection of bits somewhere on the Network
The reasons for a standard or virtual anything have been discussed,
length, elsewhere and will not be elaborated upon here. Rather
attack the entire issue of virtual pathnames, I wish only to propose
standardized SYNTAX for specifying pathnames. Such a standard will
useful for 1) users who are unfamiliar with a site or who use
different sites and do not want to have to remember each site'
idiosynchracies, 2) programs accessing data at several other sites,
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 /
::= any printable character that is not in
succeeding field and that
acceptable to the object site: For
aesthetics and to facilitate human parsing
anytime is a left-
character (<, [, (, _), must
the complementary right-bracket
(>, ], ), |).
::= any sequence of characters acceptable to
object site. This is the actual data
with the file, directory, device (
whatever) name
::= Either 1) the same character as
2) if the character is
left-bracket character (<, [, (, _) then
complementary right-bracket (>, ], ), |).
-1-
::= carriage-
::= line-
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
in fields
indicates what part of the pathname the next is going
refer to: The single-character keys are abbreviations for the
full-word keys
ARE order dependent, but defaulted ones may be omitted.
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,
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
nickname or number: The default radix
ten; a numeric string ending with "H
indicates hexadecimal, "O"(oh)
octal, and (gratuitously) "D"
decimal
PERIPHERAL or P: Peripheral device being referred to
DIRECTORY or D: Name of a directory which contains
pointer to the entity (directory
filename) specified in the
:
FILE or F: Basic name of the file or data set
TYPE or T: Optional modifier to filename: (
calls it the extension.)
SITEPARM or S: A parameter, such as an
specification or version number,
to the object site. The content of
field must serve to identify
Siteparm is involved. Each site will
responsible for defining the syntax
Siteparm s it will accept
-2-
Some reserved PERIPHERAL s
DISK or DSK: Immediately accessible, direct-
storage
ONLINE or ONL: Whatever immediately-accessible (
in fractions of a second) storage
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
are permissible: The user should
to wait minutes or hours before
able to access OFFLINE files
PRINTER or PTR: Any available line-printer
DOCPRINTER or DOC:Upper-lower case line printer,
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
defaults are offered only as guidelines
Network:
Host: The host interpreting the
Peripheral: ONLINE (DISK
Directory: The user's current "working" directory
usually set by the logon process
Filename: None
Type: None
Siteparm: None
-3-
General
The only field that must be considered in relation to any host's
syntax is the escape-to-NVP field (The per-cent sign as the
character of a pathname specification): It is not currently known
conflict with any host's syntax
Exclamation mark (!) is the only other character that seems
(on the assumption that the character should be a graphic): Its use
cause minor problems at Multics; but more importantly as a graphic, it
too similar to the numeral "1":
The syntax is intended to be adequate for all hosts, so any given
of it may be inappropriate for any given host
A site is expected to permit specifications in a given field iff
site already has a way of accepting the same information
I believe that any modifications to the syntax will be
additions, rather than wholesale redesign, and thus can be deferred for
while. Currently, any undefined attributes must be specified in
Siteparm field
Perhaps Version, Access protection and Accounting, as well as other
of information, should be made standard s, rather than buried
Siteparms. I expect that the next version of the NSDP
specification will include them as s, but I would like to wait
some comments from the community
The syntax does not currently allow addressing any collection of
smaller than a file: This can be remedied by adding PAGE, BYTE and
s; but, again, I would like to solicit some comments first
A pathname specified in the proposed syntax is fairly easy to type but
quite ugly to read: So, at the expense of design cleanliness,
/ syntax was modified in an attempt to remedy
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
Multics conventions: That is
(Network)[Host]Peripheral:Directory>Filename:Type;
Though visually more attractive and generally quicker to type, it
extensibility. For example, adding Version number or Access protection
standard fields would be difficult
It is suggested that human interfaces be built to translate to/from
syntax and the user's standard environment
-4-
Some sample pathnames
%H[ISI]DF(MESSAGE)T/TXT/S(P77O4O4) refers to
protected message file at ISI (MESSAGE:TXT;P77O4O4).
%H/OFFICE-l/D>JOURNAL>FT.NLS. refers to NIC
document #18659 (Tenex file l8659:NLS):
%H/65/D.ARP061.D.LAD:F.DOCUMENT. refers to a
ARPO6l:LAD.DOCUMENT at UCLA-CCN. Note the use of multiple
fields
%H[540]D//D>udd>D>Comp=net>D>Map>F(Mail) refers to
CompNet>Map>Mail at Mit-Multics. Note that the initial NSPD
field is empty. This conforms to Multics' method of starting
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
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
