summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc645.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc645.txt')
-rw-r--r--doc/rfc/rfc645.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc645.txt b/doc/rfc/rfc645.txt
new file mode 100644
index 0000000..ce4ee2d
--- /dev/null
+++ b/doc/rfc/rfc645.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group D. Crocker
+Request for Comments: 645 UCLA-NMC
+NIC: 30899: JUNE 1974
+Obsolets: 615 (NIC: 21531)
+
+
+ Network Standard Data Specification Syntax
+
+INTRODUCTION
+
+ This document defines the basic components of a Network Standard Data
+ Specification (NSDS) syntax. A NSDS is intended to provide a
+ mechanism for specifying all the attributes of a collection of bits.
+
+ The definition of a complete NSDS syntax is expected to require an
+ extended effort. Therefore the initial scope of this document has
+ been constrained to provide only a basic syntactic environment.
+
+ In order to demonstrate a specific use for the NSDS, this document
+ also provides the complete syntax for specifying the PATHNAME
+ attributes of a collection of bits, to the level of a file. Addition
+ of new subparamters should not be difficult.
+
+ In this context, "pathname" referes to that information which
+ specifies the LOCATION of a collection of bits.
+
+ The pathname syntax is essentially the same as that proposed in
+ RFC 615 (NIC -- 21531,). Modifications were made in order to
+ allow for graceful addition of other file attributes and to
+ optimize use by humans and by processes.
+
+ I would like to thank Jon Postel, Jerry Popek, Vint Cerf, Jim White,
+ Charlie Kline, Buz Owen, Ken Pogran, Jerry Burchfiel and Tom Boynton
+ for their suggestions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 1]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+HUMAN AND MACHINE FACTORS
+
+ Since computers tend to prefer more highly structured envireonments
+ than do humans, aspects of the NSDS syntax are permitted to be
+ different for computers than they are for humans. Specifically:
+
+ For computers (highly-structured mode), keyword fields are fixed
+ length and the variable-length data subfields are prefaced by a
+ byte count. Additionally in highly structured mode, the possible
+ contents of data subfields may be more constrained than for the
+ semi-structured mode.
+
+ For humans (semi-structured mode), keyword subfields are variable
+ length and data subfields are surrounded by delimeter characters.
+ A keyword must be long enough to distinguish it from other
+ keywords. That is, partial-name specification is permitted.
+
+STRUCTURE OF THE GENERAL SYNTACTIC ENVIRONMENT
+
+Overview:
+
+ A NSDS is prefaced by one or two percent signs, followed by a set of
+ fields subject to context-free interpretation, and terminated with a
+ space. Pathname fields precede any other file attribute
+ specifications.
+
+The BNF:
+
+ <NSDS> ::= <flag> <path> <otherstuff> <sp>
+
+ <flag> ::= % / %%
+
+ <path> ::= pathname fields, as described below.
+
+ <otherstuff> ::= fields for specifying data storage and accesss
+ characteristics, to be defined later.
+
+ <sp> ::= space.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker [Page 2]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+Comments:
+
+ The <flag> indicates escape-tp-NSDS-syntax. One percent sign
+ indicates semi-structured syntax, two indicate that highly-structured
+ syntax is being used.
+
+ Only <flag> must be considered in relation to any host's current
+ syntax. 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 basic (highest-level) syntax for individual <path> and
+ <otherstuff> fields is the same, as defined below. The remaining
+ lower-level syntax (including permissible keywords and data subfield
+ contents) for <otherstuff> fields is left for later.
+
+BASIC UNITS OF SUBSTRUCTURE
+
+Overview:
+
+ A semi-structured field begins with a varying-length descriptor. The
+ descriptor is followed by a varying-length data subfield, which is
+ surrounded by delimeter characters.
+
+ Highly-structured fields have fixed-length descriptors, followed by a
+ data byte-count, followed by the data
+
+BNF for individual fields:
+
+ <field> ::= <machine> / <human>
+
+ <machine> ::= <stru-field> / <stru-field> <machine>
+
+ <stru-field> ::= <stru-key> <count> <data>
+
+ <stru-key> ::= 4-character field definition keyword; see
+ below.
+
+ <count> ::= one-byte binary count of number of bytes of
+ <data>.
+
+ <human> ::= <h-field> / <h-field> <human>
+
+
+
+
+Crocker [Page 3]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+ <h-field> ::= <h-key> <h-rest>
+
+ <h-key> ::= Variable-length field definition keyword; see
+ below.
+
+ <h-rest> ::= <l-delim> <data> <r-delim>
+ / <l-delim> <data> <r-delim> <h-rest>
+
+ <l-delim> ::= any non-alphabetic printable character that is
+ not in the succeeding <data> subfield and that
+ is acceptable to the object site. For visual
+ aesthetics and to facilitate human parsing,
+ anything <l-delim> is a left-bracket character
+ (<, [, (, -), <r-delim> must be the
+ complementary right-bracket
+ character (>, ], ), |).
+
+ <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 (>, ], ), |).
+
+ <data> ::= any sequence of characters acceptable to the
+ object site. This is the actual data subfield
+ with the file, directory, device (or whatever)
+ attribute value.
+
+Elaboration:
+
+ Case is irrelevant to the syntax, though some sites will care about
+ case in <data> subfields.
+
+ They key (<stru-key> or <h-key>) indicates what part of the NSDS the
+ next <data> subfield refers to.
+
+ <R-delim> amd <l-delim> are used to delimit the beginning and end of
+ the <data> subfield.
+
+ <Fields> for pathnames ARE order dependent, but defaulted ones may be
+ omitted. The order is as indicated for <key>s, below. That is,
+ Network, Host, ... Siteparm.
+
+ Keywords are used, even though pathname attributes are ordered, to
+ facilitate the addition of new fields and to be consistent with
+ the syntax for <otherstuff> fields which are expected to be
+ unordered.
+
+
+
+
+
+Crocker [Page 4]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+ <Field>s or <h-rest> subfields may be repeated, as permitted by the
+ object site. A series of <h-rest> subfields, without any <h-key>
+ subfields is interpreted as a series of <h-field>s with identical
+ <key>s.
+
+ Also, note that since the syntax does not constrain the contents
+ of <data> subfields, compound names within a single <data>
+ subfield are allowed. The delimeter used to separate names within
+ a <data> subfield must be different from <l-delim>/<r-delim> and
+ the same as that used at the object site, since that is the only
+ site which will be able to interpret the <data> subfield.
+
+ The validity of any combinations of <field>s is entirely site-
+ dependent. For example, if a site will accept it, an NSDS with a
+ Host field, and nothing more, may be permissible.
+
+ The validity of <data> subfields' contents is generally site-
+ dependent. Some exceptions are noted below.
+
+PATHNAME ATTRIBUTES AND VALUES
+
+ The basic syntax does not need to be altered, to create the ability
+ to specify pathnames. Only <key> values need to be defined.
+
+ Definitions of Pathname <key>s:
+
+ They keyword for semi-structured mode is given first, followed by
+ the keyword for highly-structured mode, if different. For
+ highly-structured mode, keywords that are less than four
+ characters should be padded with blanks at the right.
+
+ Semi Highly Meaning
+
+ NETWORK NET Reference to the network (e.g., ARPA)
+ connected to the HOST that contains or will
+ contain the collection of bits.
+
+ HOST Reference to host machine that contains or
+ will contain the collection of bits. Also see
+ section on "Numbers".
+
+ PERIPHERAL PERI Peripheral device being referred to.
+
+ VOLUME ID VOL The volume (e.g., specific tape reel or disk
+ pack) associated with the named peripheral
+ device.
+
+
+
+
+
+Crocker [Page 5]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+ DIRECTORY DIR Name of directory which contains a pointer to
+ the entity (directory or filename) specified
+ in the following <field>.
+
+ FILE Basic name of the file (data set).
+
+ TYPE Optional modifier to the filename. (Tenex
+ calls it the Extension.)
+
+ VERSION VER Optional third party to basic filename.
+ Usually used to distibguish updated files.
+ The <data> subfield will usually contain a
+ number.
+
+ SITEPARM SITE A parameter, such as an access specification
+ or account number, peculiar to the object
+ site. The contents of the <data> subfield
+ must serve to identify what Siteparm is
+ involved. Each site will be responsible for
+ defining the syntax of Siteparm <data>
+ subfields it will accept. Note that the
+ SITEPARM field allows specification of other
+ than pathname data (e.g., access and account
+ number).
+
+Some reserved PERIPHERAL <data>s:
+
+ The alternate forms are merely for typing convenience and are not
+ related to the semi/highly structure modes.
+
+ DISK or DSK: Immediate, direct-access secondary
+ 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.
+
+
+
+
+
+
+Crocker [Page 6]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+ 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.
+
+ LINE PRINTER or LPT: Any available line-printer.
+
+ DOCUMENT PRINTER or DOC: Upper/lower case line printer,
+ preferably with 8 1/2" X 11" unlined
+ paper.
+
+ PAPER TAPE READER or PTR: Paper tape reader.
+
+ PAPER TAPE PUNCH or PTP: Paper tape punch.
+
+ CARD PUNCH or PUN: Standard 80-column card punch.
+
+ CARD READER or RDR: Standard 80-column card reader.
+
+ OPERATOR or OPR: System Operator's console.
+
+ CONSULTANT or CON: On-line consultant.
+
+
+DEFAULTS FOR PATHNAME <DATA> SUBFIELDS:
+
+ Often, the appropriate default will be the last-used value. However,
+ defaults will generally be context dependent. Consequently, the
+ following defaults are offered only as guidelines:
+
+ Network: ARPA.
+
+ Host: The host interpreting the NSDS.
+
+ Peripheral: ONLINE (DISK).
+
+ Volume id: Catalogued system space.
+
+ Directory: The user's current "working" directory, usually set
+ by the logon process.
+
+ Filename: None.
+
+ Type: None.
+
+ Siteparm: None.
+
+
+
+
+Crocker [Page 7]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+NUMBERS
+
+ The following scheme is recommended for specifying numbers in <h-
+ field> data subfields:
+
+ A sequence of numberic characters, optionally followed by a
+ character indicating the radix. The default radix is ten. "H"
+ indicates hexadecimal; "O" (oh) indicates octal; "B" indicates
+ binary; and (gratuitously) "D" indicates decimal.
+
+ In <stru-field> data subfields, the number should be pure binary.
+ Therefore, reference to a host on the Arpanet would require one 8-bit
+ byte.
+
+GENERAL COMMENTS
+
+ 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 if
+ that site already has a way of accepting the same information.
+
+ Having two modes of specification (highly- and semi-structured)
+ may prove to be unnecessary. They are defined here merely as a
+ convenience for experimentation.
+
+ I believe that 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.
+
+ The first version of the syntax was a mix of Tenex and Multics
+ conventions. That is:
+
+ (Network)[Host]Peripheral:Directory>Filename.Type;Sireparm
+
+ Through visually more attractive and generally quicker to type, it
+ lacks extensibility. For example, adding a version number as a
+ standard field would be difficult.
+
+ It is asserted (conceded) that, as long as extensibility is kept as a
+ design goal, no standardized [semi-structured] syntax will be as
+ pleasant to use as currently exists on some systems.
+
+
+
+
+
+
+
+
+Crocker [Page 8]
+
+RFC 645 Network Standard Data Specification Syntax June 1974
+
+
+SOME SAMPLE PATHNAMES
+
+ Pathnames in NSDS that occupy more than one line, below, do so only
+ because they are too long for a single line. Bracketed numbers
+ (e.g., <8>) indicate a single byte with the number as its decimal
+ value. Blanks (spaces) are indicated by <sp>.
+
+
+ My message file at ISI (<DCROCKER>MESSAGE.TXT;P770404):
+
+ Semi-structured
+
+ %H[ISI]D<DCROCKER>F(MESSAGE>T(TXT)S/P770404/<sp>
+
+ Highly-structured
+
+ %%HOST<1><86>DIR<sp><8>DCROCKERFILE<7>MESSAGETYPE<3>TXTSITE<7>P
+ 770404<sp>
+
+ ARP061.LAD.DOCUMENT at UCLA-CCN. (Note the use of multiple Directory
+ fields):
+
+ Semi-structured
+
+ %H[65]DIR[ARP061][LAD]F[DOCUMENT]<sp>
+
+ Highly-structured
+
+ %%HOST<1><65>DIR<sp><6>ARP061DIR<sp><3>LADFILE<8>DOCUMENT<sp>
+
+ >udd>CompNet>Map>Mail at Mit-Multics. (Note that the initial NSDS
+ Directory <data> subfield is empty, in keeping with Multics' method
+ of starting at the top of its directory structure):
+
+ Semi-structured
+
+ %h(540)DI[]DI[udd][CompNet]D(Map)FIL(Mail)<sp>
+
+ Highly-structured
+
+ %%HOST<1><44>DIR<sp><0>DIR<sp><3>uddDIR<sp><7>CompNetDIR<sp><3>
+ MapFILE<4>Mail<sp>
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Alan Ford 12/99]
+
+
+
+
+
+
+Crocker [Page 9]
+