Network Standard Data Specification syntax
RFC 645

Document Type RFC - Unknown (June 1974; No errata)
Obsoletes RFC 615
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 645 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text