RFC 645

Network Standard Data Specification Syntax 🎀

Okay bestie, let's get into RFC 645 💖 It's by D. Crocker from UCLA-NMC, dated June 1974 🦋, and it's the glow-up of RFC 615 (NIC 21531), so it obsoletes that one 💅 The NIC number for this doc is 30899 ✨. The title block doesn't list a category, and it doesn't say it updates anything, so I'm not adding either.

INTRODUCTION ✨

So a Network Standard Data Specification (NSDS) is a way to describe all the attributes of a collection of bits 🧚 Like, every single one. Defining a complete NSDS syntax is gonna take a whole era of work, so this doc keeps its scope small and only gives a basic syntactic environment 💅

To show what it can do, the doc also gives the complete syntax for specifying the PATHNAME attributes of a collection of bits, down to the file level 📁 Adding new subparameters shouldn't be too hard either 🙌

"Pathname" here means the info that says where a collection of bits lives, its LOCATION 📍

The pathname syntax is basically the same as the one in RFC 615 (NIC -- 21531,) 🔁 but it got tweaked so new file attributes can be added smoothly, and so it's easier for both humans and processes to use 🫶

The author 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 🌸 Iconic squad 👑

HUMAN AND MACHINE FACTORS 🤖

Computers are super into highly structured environments, while humans are more chill about it, so parts of the NSDS syntax are allowed to look different depending on who's reading it 💻 Specifically:

• For computers (highly-structured mode), keyword fields are fixed length, and the variable-length data subfields get a byte count in front 🔢 In this mode, the stuff allowed in data subfields can also be more constrained than in semi-structured mode.
• For humans (semi-structured mode), keyword subfields are variable length, and data subfields are wrapped in delimiter characters 🎀 A keyword must be long enough to tell it apart from other keywords. Partial-name specification is permitted, so you can type less 🙈

STRUCTURE OF THE GENERAL SYNTACTIC ENVIRONMENT 🏗️

Overview

An NSDS starts with one or two percent signs, then a set of fields that get context-free interpretation, and it ends with a space ✨ Pathname fields always come before 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.

Comments

• The <flag> tells you it's time to escape into NSDS syntax 🚪 One percent sign means semi-structured syntax, and two mean highly-structured syntax 🎀
  • 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 🙌
    • The exclamation mark (!) is the only other character that seems like it could work, assuming it should be a graphic. It would cause minor problems at Multics, but more importantly, as a graphic it's too similar to the numeral "1" 😭

The basic (highest-level) syntax for individual <path> and <otherstuff> fields is the same, as defined below. The rest of the 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 starts with a varying-length descriptor 🌀 That's followed by a varying-length data subfield, wrapped in delimiter characters 🎁

Highly-structured fields have fixed-length descriptors, then a data byte-count, then 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>
<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 doesn't matter to the syntax, though some sites will care about case in <data> subfields 🔠
• The key (<stru-key> or <h-key>) says which part of the NSDS the next <data> subfield refers to 🔑
• <r-delim> and <l-delim> mark the beginning and end of the <data> subfield 🎯
• <Fields> for pathnames are order dependent, but defaulted ones may be omitted. The order follows the keys listed below: Network, Host, ... Siteparm 📋
  • Keywords are used even though pathname attributes are ordered. That makes it easier to add new fields, and it matches the <otherstuff> fields, which are expected to be unordered 🧩
• <Field>s or <h-rest> subfields may be repeated, as permitted by the object site. A series of <h-rest> subfields with no <h-key> subfields gets read as a series of <h-field>s with identical keys 🔁
• The syntax doesn't constrain what goes inside <data> subfields, so compound names inside a single <data> subfield are allowed 💬 The delimiter used to separate names inside a <data> subfield must be different from <l-delim>/<r-delim>, and it must match the one used at the object site, since that's the only site that can interpret the subfield 🗝️
• The validity of any combination 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 too. Some exceptions are noted below 🚦

---

DEFAULTS FOR PATHNAME <DATA> SUBFIELDS ✨

Okay so defaults are giving "remember what you picked last time" 💅. Often the appropriate default will be the last-used value 🫶. Defaults are super context dependent though, so these are only guidelines, not rules 🌸. Here's the vibe:

• 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.

NUMBERS 🔢

The recommended scheme for writing numbers in <h-field> data subfields is giving clean and simple energy 🦋. You get a sequence of numeric characters, and you can optionally add one character at the end to tell everyone the radix. The default radix is ten. H means hexadecimal ✨, O (say it like "oh") means octal, B means binary, and D means decimal, which is gratuitous 💀 but we love a dramatic letter 🎀.

In <stru-field> data subfields, the number should be pure binary 🤖. Therefore, referencing a host on the Arpanet would require one 8-bit byte 💜.

GENERAL COMMENTS 💬

The syntax is meant to be adequate for all hosts, so any given portion of it might be totally 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. Iykyk 🫶.

Having two modes of specification (highly- and semi-structured) may prove to be unnecessary. They're only defined here as a convenience for experimentation 🧪.

I believe modifications to the syntax will be graceful additions rather than a wholesale redesign, so they can be deferred for a while 🦋. For now, any undefined attributes must be specified in a Siteparm field.

The first version of the syntax was a mix of Tenex and Multics conventions, and it looked like this:

(Network)[Host]Peripheral:Directory>Filename.Type;Sireparm

Though it's 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 what currently exists on some systems. Honest, but iconic 👑.

SOME SAMPLE PATHNAMES 📂

Pathnames in NSDS that take up more than one line below only do that because they're too long for a single line 📏. Bracketed numbers (e.g., <8>) mean a single byte with that number as its decimal value 🔢. Blanks (spaces) are shown as <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] 🦋