Zmail mail-file format semantics

Public C303 evidence

The public source is maintained LM-3, not pristine 1983 media. The selected Fossil check-in is 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91.

The canonical public links are in Sources.

Licensed G85 source evidence

These suffixes identify local evidence without publishing its machine-specific root. The complete 47-file selection and its content digests are in the declared-build source manifest.

The G85 source profile is not automatically identical to the preserved Genera-8-5.vlod world. Any function-level world claim needs a separate oracle record.

Buffer state

Each mail-file buffer owns at least:

The real message interval contains format wrapper material. The visible interval excludes status/separator material and may exclude original headers. Moving a message between incompatible adapters rewrites the wrapper and may reformat headers; a clone MUST NOT treat every message as one undifferentiated byte string.

Line model

Source line objects do not store a trailing newline as part of their active character length. The loader receives a line, its active length and an EOF flag. Specifications below use these tokens:

Fixture notation is descriptive; tracked documentation does not contain recovered licensed mail bytes.

Reader result algebra

The reader's boundary callback returns:

Format state is reset to nil at each new message. The common reader sets its start line only after a nonblank line is seen, but it still invokes the adapter callback with a null start on blank input. If that callback reports an end, later buffer- pointer construction can fault on the null start; a whitespace-only file therefore cannot be assigned a generic no-message result without the adapter-specific branch.

G85 third boundary value

G85 adds an explicit new-line remainder value for a numeric split. It truncates the current line to the included prefix and stores new-line as the next message seed. C303's Tenex implementation instead mutates the line graph when recovering a mid-line boundary. These are not equivalent failure traces.

C303 host computation

Every content probe reads the first line and resets the stream pointer to zero.

Rmail's *APPEND* test is reached only in the non-Babyl ITS branch. The C303 source contains no generic magic-priority pipeline.

G85 host computation

G85 separates four generics: native choices, pathname-derived default, host fallback, and content-derived actual format. Text is appended to a host's native choice list if the native method omitted it.

Tenex and Unix host option methods define Append as true for every format. Comments that LMFS/Mac defaults should become KBIN are non-executable and MUST NOT change the strict table.

G85 probe order and pointer invariant

KBIN recognition precedes Babyl recognition. KBIN accepts either its native element type or a four-character narrow stream. The latter constructs 16-bit opcode/version pairs in normal and byte-swapped order, accepts only the exact format opcode and a version within the source bounds, and resets the pointer. Babyl then checks the exact first line Babyl Options: and resets the pointer. Directory checks the exact first line *Mail file directory* and resets the pointer. Host fallback runs last.

Every normal return and every reported apparent-format path MUST leave the stream at offset zero. A short four-character read, fat character, unsupported element type or failed bound check is a KBIN nonmatch, not an exception-driven KBIN selection.

Load algorithm

For each message the C303 loop:

1. restores a retained start line from the previous call, if present;
2. otherwise reads a line with leader metadata;
3. at EOF with no nonempty line, returns no message when none was started, or supplies the adapter's canonical last line when a message was started;
4. skips leading lines containing only spaces or tabs when choosing the real start;
5. calls the adapter boundary method with line, active length, state, EOF and the message's first line;
6. when the callback returns an end result, constructs pointers from the retained start and publishes the message; a null start can fault before publication;
7. retains a start-next line or a line inserted by callback recovery for the next invocation; and
8. resets adapter state before the next message.

Previously published messages remain in the array if a later format parser fails.

Write pipeline

New or moved messages are parsed before copying when necessary, receive the target adapter's real header and trailer, have their end marker normalized, and have visible headers reformatted only when source and destination formats are not header-compatible. Status-in-file updates occur before serialization when the message tick exceeds the buffer's status-update tick.

C303 uses the source buffer's line graph as its serialization representation. It does not define one universal atomic replacement. An implementation must expose its selected host's stream close/version result and must retain dirty/partial state on error.

Grammar and boundary

rmail-file    = [ append-line CR ] *rmail-message
append-line   = "*APPEND*"
rmail-message = message-text delimiter-line CR
delimiter-line = *prefix-char US *delimiter-tail
delimiter-tail = *(SP / TAB / FF)

US may occur at any index in the delimiter line. The boundary is valid only when every later character is space, tab or formfeed. The visible message ends immediately before US; the real wrapper consumes the whole delimiter line and starts the next message on the following line. At EOF after message text, the loader supplies a canonical one-character US line.

Header and options

The exact first line *APPEND* is a file header and sets Append true. It is removed from the message stream and retained in the buffer header. Any other first line is message input and leaves Append false. Updating options inserts or removes precisely that header line.

Serialization

Before each appended message, the target normalizes the previous message end to a line containing US. A message moved into Rmail receives no leading wrapper and one Return as its real trailer. Header parsing is the ITS header parser. Rmail persists no per-message status record beyond message header/body text.

File envelope

babyl-file      = option-section US [ FF ] CR *babyl-message
option-section  = 1*option-line
babyl-message   = *blank-line status-line CR original-area eooh-line CR display-and-body
                  delimiter-line CR
eooh-line       = "*** EOOH ***"
delimiter-line  = US [ FF ]

The option reader appends each input line to the header interval and stops at the first line containing US; it does not require US to be the only character. The first-message locator searches the header interval for that line. If it contains only US, C303 appends FF before returning the following line as the first message.

For a newly constructed Babyl file, Version defaults to 5 and the header ends in US. A newly inserted message receives a leading blank line, *** EOOH ***, a following blank line, and a trailing Return. When normalizing an existing message, the final delimiter is US FF except for the final non-append normalization path, where bare US is allowed. The in-memory message end is before the delimiter.

Option-line grammar

An option line is split at its first colon. Its name is uppercased and interned as an option key. With no colon, the value is Boolean true. With a colon, spaces and tabs immediately following it are skipped. The remainder is decoded as follows:

Known option-specific parsers override the generic rule. Unknown option keys and values are retained in the property list. When updating the file, C303 edits a known line in place, removes it when all properties represented by that line became false, and appends nonfalse known properties not previously represented. Babyl Options: is forced to be the first logical property.

The empty-tail failure is a strict C303 edge, not an invitation to substitute NIL or an empty string: after whitespace skipping leaves the index at active length, the generic branch indexes that position while testing the special-character set. An unknown option whose value is an empty string can fail again during generic printing, which likewise inspects character zero. A safety-corrected overlay MAY preserve an empty string, but MUST report the divergence. G85 adds an explicit empty-tail parse case, although its generic printer retains the empty-string character-zero defect.

C303 Babyl option map

The settable list is Append, Reverse-New-Mail, Version, Mail, Owner, Sort, Delete-Expired, No Reformation, Summary-Window-Format and Gmsgs-Host. Babyl-P and the keyword registry fields are not ordinary UI-settable options.

Version 5 status grammar

status-v5    = reformatted "," basic-labels "," user-labels
reformatted = "0" / nonzero-text
basic-labels = *(SP basic-name ",")
user-labels  = *(SP user-name ",")

The parser is comma-driven. 0 means not reformatted; any other first field means reformatted. Basic names are case-insensitively resolved through this ordered C303 table: last, unseen, deleted, bad-header, answered, forwarded, redistributed, filed, recent. badHeader is first normalized to bad-header. An unknown basic name signals a Zmail error. User names reuse a case-insensitive keyword registry entry or create an interned uppercase symbol while retaining the first observed display spelling.

The serializer emits basic labels in exactly the table order, then user keywords in message order. Every emitted label is preceded by one space and followed by a comma.

Version 4 status grammar

A v4 status line begins with optional D for Deleted, followed by an octal integer, followed by zero or more space-plus-{keyword} items. The five low bit positions map, in order, to Reformatted, Unseen, Losing-Headers, Answered and Filed; bit 1 is XORed with octal 2 so the stored sense represents Seen rather than Unseen. Serialization starts with octal 10000, adds those property bits, applies the Seen inversion, appends each keyword in braces, and overwrites the first character with D when Deleted.

Header split and malformed input

C303 skips blank lines to find the status line, parses it, then searches up to the message end for *** EOOH ***. When found, lines after the status and before the sentinel are the original header area, and the visible message starts on the line after the sentinel. If the sentinel is absent, the selected C303 method does not raise the explicit contained BAD-BABYL-MSG condition introduced in G85; it leaves the status line as the split reference and starts visible text on its following line. Strict compatibility preserves this malformed-input result.

The blank-line skip has no end-of-message guard. A wrapper containing only blank lines can therefore walk beyond the real interval and fail; C303 does not convert that case into G85's contained Null-Message condition.

Status record

tenex-status = received-date "," decimal-byte-count ";" octal-status

The date prefix ends immediately before the comma. The so-called byte count is the decimal field between comma and semicolon. At this layer it is a PDP-10 logical character count: an ordinary stored character contributes one and each Lisp-machine Return contributes two for the foreign CRLF representation. The status field is octal. Low bits, after XOR with one, map in order to Unseen, Deleted, Always-Show and Answered.

Boundary recognition and later status parsing are deliberately different. The boundary method recognizes only comma, later semicolon, and a decimal count between them; it does not validate the date or octal status. The before-parse method accepts any nonempty first line with comma and later semicolon, stores a false Received-Date when date parsing fails, and may signal while parsing the octal flags. Whether or not those delimiters exist, it then moves the visible message start to the following line. A strict clone MUST preserve this unconditional first-line hiding.

The byte count covers the visible message region and counts every Return as two PDP-10 characters. On rewrite, the received date falls back from Received-Date to Date and then the current time; the status field is exactly 12 octal digits; and the timezone text, date, clock and decimal byte count are regenerated.

Boundary state machine

Let remaining be the current Tenex state.

1. The first line is probed for comma, semicolon and a decimal count. A recognizable line installs that count without subtracting the status line. An unrecognizable one enters recovery state 1.
2. If remaining >= line-length, subtract line-length + 2; the message ends after the line when the result is nonpositive.
3. Otherwise the expected boundary is inside or before the line. Search from the expected offset for a comma and later semicolon whose intervening field is a decimal count. This test still does not validate a date or status field.
4. If such a probable next status exists and the expected offset was nonzero, insert a Return at that offset, add two to the previous message's stored byte count, end the current message, and let the common reader consume the newly split suffix on its next iteration. The newly parsed count is returned as callback state but is discarded when the common reader resets state for the next message.
5. If no probable status is found, set state to 1, do not end the message, and scan each later line until one resembles a status line.

Two strict defects follow from those rules. Recovery state 1 splits a later candidate at character index one, so the first character remains attached to the malformed message and the suffix begins one character into the candidate. A declared count of zero is also not treated as end-of-message on the status line: on a later nonempty candidate, entry state zero suppresses the split but returns true, causing that whole candidate line to remain in the preceding real interval rather than seed the next message. These are source-profile results, not recommended repair policy.

The nonzero-offset repair mutates the in-memory source text and, when the original status count can still be parsed, its earlier status count. It is not strict rejection and it is not transactional. A safe parser MAY offer rejection as a separate mode.

Boundary recognition

The first nonblank line starts a message. A later line starts the next message only when all these tests pass:

1. it starts exactly with From ;
2. it contains another space after the beginning of the sender portion;
3. after that position, one of the configured weekday names occurs; and
4. at least one decimal digit occurs after the weekday occurrence.

At EOF the final active line length terminates the message. The boundary line is retained as start-next. Unlike G85, a bare From prefix is insufficient.

Envelope parse and synthesized headers

The envelope parser examines a consecutive run of lines beginning From or >From and selects the last line in that run as its parse candidate; if no movement was possible, it uses the original first line. Starting after the five-character marker, it grows the sender field word by word until the next word matches a weekday abbreviation. Address and date errors are stored as report strings rather than re-signaled by this helper.

The fixed start offset remains five even when the selected candidate starts with the six-character >From prefix. Thus a selected escaped candidate is not generically unescaped: its leading > changes the field alignment and can yield an empty or malformed sender parse. Only the first real line is later hidden, so any additional candidate lines remain in the visible interval. A clone MUST NOT turn this narrow, source-visible scan into mboxrd unescaping.

Only the first real line is removed from the visible interval. Parsed envelope sender and date are stored as UNIX-FROM-HEADER; the date supplies Received-Date and, if missing, Date; the sender supplies From if missing. The selected source does not define a general mboxrd body unescaper. Consecutive >From handling above is an envelope-parse heuristic, not permission to claim complete >From round-trip support.

Serialization

The C303 rewrite test compares current and saved From address entries pairwise for equal Name and Host fields but does not compare list lengths. Because the parallel loop stops with the shorter list, equal common prefixes—including two empty lists—can suppress a needed rewrite. Otherwise it rewrites or inserts a From line, prints the current address list, then an optional ctime-shaped date using decoded Received-Date. The ordinary message headers follow. The source has no adapter method that escapes arbitrary body lines beginning From ; strict conformance MUST test both the prefix-length defect and the absence of body escaping rather than silently claiming modern mbox compatibility.

Detection and boundaries

VMS is selected only on a VMS pathname when the first line equals one formfeed. Each message begins with a formfeed line; a later formfeed line is retained as the next message start. EOF ends the current message. The formfeed wrapper is excluded from visible text. A new message receives formfeed-plus-Return before its content and one Return after it.

Header variants

The first visible line is parsed as a fixed VMS From record. The sender occupies the 12-character field after the FROM:<TAB> prefix, trimmed of spaces; the following date portion is parsed if possible, with an error report string retained on failure.

If that sender is exactly CHAOSMAIL, the remaining message is parsed as ordinary headers. Otherwise the parser conditionally consumes, in order:

1. a TO:<TAB> line, split at commas into nonempty space-trimmed names on the pathname host; then
2. a SUBJ:<TAB> line, whose value is the substring after the tab.

The fixed sender/date always supplies Received-Date and missing Date/From properties. On reformat, the writer emits a CHAOSMAIL-style From line derived from Received-Date or Date, prints known ordinary headers, inserts a blank line, and removes the old visible header region. Multics is not registered in this profile.

Verification before message input

Starting a load changes the buffer to :LOADING, opens with the adapter's element type, verifies the format, loads any file header, queues mail checks, then reads messages. The default verifier rejects an incompatible stream element type, a KBIN signature, and the Babyl marker. An invalid byte size causes a reopen with default element type and an apparent-format condition.

On the first eligible wrong-format condition, the caller aborts this load, changes the existing buffer's flavor to the supplied apparent format, and retries. A condition without an apparent format is re-signaled. Later retries use the explicit different-format restart. Explicit Format and interactive format selection disable the automatic first switch. These format errors occur after buffer construction and must preserve the parent specification's retry order.

Load algorithm

For every text adapter other than Directory and KBIN, G85:

1. restores NEXT-MSG-START-LINE, otherwise reads the next line;
2. returns no message at EOF when no message exists and the line is absent or empty;
3. constructs a message only on the first line that is not entirely space or tab;
4. invokes the four-argument boundary method;
5. inserts the whole line for nil/true, the positive prefix for a positive integer, no characters for start-next or integer zero;
6. saves the boundary's explicit remainder or retained current line as the next start; and
7. returns the complete message plus whether more input may remain.

The generic parse wrapper converts an uncaught message parse error into Unparseable under an explicit “mark and continue” restart. Format-specific before methods may instead attach a contained condition and return. Parsing is lazy and may happen after the structural load, so “file loaded” does not imply every message header was successfully interpreted.

Save algorithm

G85 owns a per-save structure with Current-Message and an adapter-specific slot. Text formats place an interval stream in that slot; KBIN replaces it. A save from :IDLE skips file output when neither modification tick exceeds the buffer tick, but still enters :SAVED so finish work can run. Otherwise it:

1. enters :SAVING;
2. opens the selected pathname and element type for output, superseding only when the pathname's version semantics require it;
3. writes the file header;
4. writes messages in increasing sequence index while updating Current-Message;
5. enters :SAVED only after all message writes return; and
6. finishes the save, pending-inbox work, identity/ticks and close in the common profile-defined order.

An error during message n leaves prior output already written. Retry may resume with retained saving state and an explicit start index. An abort closes/abandons by the common save method and does not imply rollback of external versions or Directory member files.

Envelope and version

G85 requires the first line to equal Babyl Options:. It reads option lines into the header interval until EOF or a line containing US, but the US line itself is not inserted as an option line. Versions 4 and 5 are accepted. Version is initialized to the format default, 5, before header parsing, so an absent Version line retains 5; only an explicitly parsed absent-number or out-of-range value signals the selected source condition. This is defaulting, not an on-disk upgrade transaction.

Saving writes the updated option header, a fresh line and US; each message then writes FF CR, its wrapper/header/body representation, a fresh line and the ITS US terminator. A new v5 message leader is exactly a nonempty status line 0,,, then *** EOOH ***, then a blank line. A new v4 leader uses 0 instead.

Generic and specific option decoding

The first-colon split and generic value classes match C303, except that option keys are keywords and an empty post-colon tail is explicitly the empty string. Lisp objects are read in a standard I/O environment. Unknown lines are preserved; update logic changes only options in the buffer's declared possible set, and retains the relative order of existing lines. Babyl-P is forced first.

The explicit empty-string parse does not imply an exact empty-string round trip for an unknown option. The generic printer tests character zero before choosing display syntax and can fail on an empty string. Known options with their own printers follow those printers instead. Conformance therefore records this failure rather than normalizing it away.

The declared possible list has 15 keys: Append, Babyl-P, Reformat-Headers-P, both legacy reformatting keys, Reverse-New-Mail, Version, Mail, Owner, Sort, Delete-Expired, Keywords, Keywords-String, Summary-Window-Format and Reformat-Template. The settable subset has 10: Append, Reformat-Headers-P, Reverse-New-Mail, Version, Mail, Owner, Sort, Delete-Expired, Summary-Window-Format and Reformat-Template. Sticky options are Append, Babyl-P and Version.

Reformatting-option normalization

If Reformat-Headers-P is explicitly present, it wins:

If it is absent, No Reformation true produces Reformat-Headers-P false. Otherwise No Original :SAVE-ORIGINAL produces true, false produces :SAVE-BOTH, and true also produces true. These legacy pairs are not one-to-one; retaining the explicit new property is therefore observable.

Status mapping

The v4 bit/keyword grammar remains the C303 grammar. G85 v5 uses the same three-field shape but has these exact deltas:

• nonzero Reformatted is stored as :IN-FILE, not Boolean true;
• basic labels parse against this order: Last, Last-Undeleted, Unseen, Deleted, Losing-Headers, Unparseable, Answered, Forwarded, Redistributed, Redirected, Filed, Sent, Recent;
• Losing-Headers, Unparseable and Redirected are parseable but flagged not to be serialized as basic status labels;
• two distinct bad-header entries map to Losing-Headers and Unparseable; the first case-insensitive match controls parsing;
• label fields without a leading space are accepted for Unix RMAIL compatibility; and
• user labels are interned in the keyword package.

The writer emits only non-ignored basic properties in table order and user keywords in message order. Recent is persistable only at version 5 or later.

Contained malformed-message behavior

A blank-only message receives a Null-Message condition in Unparseable. A status parse failure is wrapped as a Bad-Babyl-Message condition and stored in Unparseable. A missing *** EOOH *** before the visible message end is handled the same way. These cases return from the format's before-parse method without moving the visible start past a valid sentinel. They do not abort the whole mail-file load by default.

When valid, lines after the status and before *** EOOH *** become an Original-Headers-Interval; lines through the sentinel are reassigned to the real wrapper; and visible text starts after the sentinel. Parsing prefers the original header interval and normalizes a parsed Re-family subject key to Subject before later daemons observe it.

Probable status predicate

A line is a probable status line only when it contains a comma, a later semicolon, and all three fields parse without error as an RFC822 date-time, a base-10 integer byte count with no junk, and an unsigned base-8 integer status with no junk. The predicate returns the parsed date, count and flags together; a failure returns four false values. As in C303, the source-named byte count drives logical foreign-file character positions here; it is not a count of bytes in a modern host encoding.

Boundary state machine

1. On the first line, a probable status installs its byte count; count zero ends the message on that line. A non-status line enters :NO-STATUS-LINE recovery.
2. EOF with an empty line ends a partial message.
3. In :NO-STATUS-LINE, non-status lines remain in the current malformed message. The next probable status line is retained as start-next and ends it.
4. For numeric state smaller than the current active line length, the first state characters end this message and a newly allocated copy of the remaining characters seeds the next message.
5. Otherwise subtract line-length + 2, and end after this line when the new value is nonpositive.

Unlike C303, G85 does not insert a Return into the current line or rewrite the prior status count during a short-count repair. Its numeric split and explicit remainder are observable.

The before-parse method marks a message with an invalid leading status line Unparseable, but a valid one stores Received-Date, maps the XOR-one low flags to Unseen, Deleted, Always-Show and Answered, and moves visible text past the status.

Serialization

The status writer chooses time from Received-Date, then Date (using the first numeric member where necessary), then current time. It produces a two-digit day, short month, year, time, timezone forced to a leading hyphen where needed, decimal byte count and 12-digit octal flags. The count is computed by running the actual message—including epsilon encoding and original-header choice—through a counting stream where Return counts as two characters. The real message end is first normalized to a line boundary.

Strict boundary delta

After the first line, every line whose first five characters are exactly From starts the next message. G85 performs no C303 weekday/digit plausibility test. EOF ends the current message at the active line length. Therefore body text beginning From splits a message unless an external producer escaped it; the selected writer does not provide a general body-line escaping pass.

Envelope and visible interval

The first real line is treated as the Unix envelope and removed from the visible interval when nonempty. Its sender ends at the first space after the marker; the rest is parsed as a universal time. Address or time failures become an error object stored as Unix-From-Header and later Losing-Headers rather than immediately aborting the file.

Trailing blank lines are normalized by deleting from the last nonblank endpoint to the real end, inserting exactly two Returns, and placing the visible end before the final blank-line wrapper. Parsed envelope values fill missing Received-Date, Date and From. When it synthesizes Date or From headers, it inserts them at the visible start, adds a blank line, records the new Headers-End pointer, fills missing hosts in To/Cc/ From from the pathname host, and refreshes the summary when those values changed.

Serialization

The selected source contains two strict serializer defects that a compatibility profile MUST expose rather than repair silently:

• A list-valued Date is reduced to its minimum. A list-valued Received-Date is also reduced, but the result is mistakenly assigned to the local Date variable while the original list remains in Received-Date. The later precedence expression still selects that list and can pass it to time decoding.
• When a parsed envelope is an error object, the method constructs a fallback saved envelope property using the user's local address and Received-Date, Date or current time. If it rewrites the physical line, however, it prints the current From header value rather than that fallback address. With no current From value, the stored property can name the local user while the emitted envelope sender is empty.

Outside those defects, the rewrite predicate requires equal From-list lengths, an existing From marker, and pairwise-equal Name and Host fields; otherwise it rewrites or inserts the record and then re-normalizes the two-Return trailer. The emitted date is ctime-shaped local date text. A safety-corrected overlay MAY use the minimum Received-Date and the fallback address consistently, but MUST identify both changes.

Index grammar

directory-index = marker CR *option-line CR CR *message-path-line CR
marker          = "*Mail file directory*"

The marker must be the exact first line. Options use the Babyl option parser and stop at EOF or the first empty line. Directory-Mail-File true is forced as the first property and Version defaults to the highest Babyl version. The declared Possible list is Directory-Mail-File, Version, Append, Reverse-New-Mail, Mail, Owner, Sort, Delete-Expired, Keywords, Keywords-String, Summary-Window-Format and Reformat-Template. The settable subset omits Directory-Mail-File, Version, Keywords and Keywords-String.

Every later line is parsed as a pathname against Zmail pathname defaults; a nonempty final line is accepted even when its read also reports EOF. Structural load creates an empty message with a File-ID tuple containing the member pathname, no file info and the file tick; it does not open the member. The same pathname object is pushed onto the buffer's remembered member list, so that list is in reverse index-read order.

Lazy member parse

On first parse, a member with absent info is opened and copied into the message's real interval. Only after copy does the implementation record stream Info and member file tick. The first member line is always parsed as a v5 Babyl status line and excluded from visible text, regardless of the Directory Version option. Failure opening a member leaves the index message unchanged. Failure during copy can leave partially inserted real-interval text, while the File-ID's Info remains false and its old tick remains; there is no rollback before a retry.

Save and allocation order

Before this method runs, the common save predicate updates modified status lines and the Directory option header. For each message in sequence order, Directory then:

1. allocate a File-ID if absent;
2. rewrite the member only when its real-interval tick exceeds the member file tick;
3. close the member, then record Info and a new tick; and
4. write its pathname to the index using the Dired string representation.

Allocation uses an in-memory [next, reserved-upper) cache. When the cache is absent, it reads the first line of UID.LISP or starts at 1, then installs [lower, 0) in the buffer. When absent or exhausted, it computes upper = lower + 200, stores that upper in the in-memory cache before opening/writing UID.LISP, and only after the write returns does it return and increment the prior lower value. A UID-write failure thus leaves [lower, upper) looking usable in memory even though the durable reservation did not complete; a retry in the same buffer can allocate lower without rewriting the UID file. This source-visible partial failure MUST be preserved by strict mode or corrected only in a named safety overlay. A member pathname has decimal name, type MSG, and newest version.

The common finish method closes the index stream, records its Info, clears the stream, deletes inserted inboxes, advances the buffer tick, and sets status to :IDLE. Directory's after method then enumerates current member pathnames, deletes each previously known pathname object not MEMQ-present in that list while ignoring File-Not-Found, and finally replaces its remembered list with sequence order. Thus member writes and UID reservation precede the index commit, while stale-member deletion follows the commit and even the transition to :IDLE; no encompassing rollback exists. A non-File-Not-Found deletion error escapes with the committed index and idle status but before the remembered list is replaced.

Fixture codec

The fixtures below are generated from ASCII text plus the token table in Line model. CR terminates each logical line. A test runner MUST record both its token stream and its host octet encoding; conformance at this layer is against tokens. This avoids pretending that Lisp-machine characters, PDP-10 file characters and modern POSIX bytes are one encoding.

For each fixture, the test oracle records:

profile, adapter, host-family, option inputs,
token-stream-before, structural-message-count,
per-message real-token-span, visible-token-span, ordered status properties,
token-stream-after-normalize, condition/restart trace, final buffer/file state

Public C303 fixture set

The public fixture generator MAY materialize these token streams as tracked test data once it records the chosen character encoding and source revision. It MUST retain the token oracle above so a POSIX newline conversion cannot silently change the claim.

G85 local semantic fixture set

The following fixture descriptions are trackable; generated bytes and mail content remain local if produced by the licensed implementation.

Adapter enumeration

For each selected profile, enumerate the registry and compare exact name, flavor, registration order, host applicability, settable/possible/sticky options, reparsability and element type. Required denominators are:

Directory is G85-only; VMS is C303-only. Text counts even though its chooser/read capability is restricted.

Parser-state exhaustiveness

Tests MUST cover every boundary return class and every state tag:

• ITS delimiter at index zero and nonzero, permitted and forbidden suffixes, EOF;
• Tenex first-line numeric, zero, positive, malformed, mid-line split, exact-line end, EOF partial, entry-state-zero candidate loss and state-one scan recovery;
• Unix first line, later valid/false boundary, consecutive >From candidates, unequal From-list lengths, empty EOF and envelope parse error;
• VMS first/later formfeed and EOF; and
• C303/G85 Text's opposite callbacks, including C303 initial/intervening blank input with a null start.

For every failure point, compare complete message count, retained next-line state, real/visible interval spans and any mutation of source text.

Option round-trip

For Babyl v4 and v5, feed every declared option as valueless, empty, string, Lisp object and invalid input where applicable. Empty generic values are failure cases in the strict profiles described above, not unconditional round-trip cases. Verify:

1. first-colon and whitespace rules;
2. known parser dispatch;
3. unknown option retention;
4. ordered update-in-place versus append/delete behavior;
5. keyword spelling/order preservation;
6. version transition rewriting of every message status line; and
7. G85 reformatting normalization; and
8. C303 empty-tail parse failure and both profiles' generic empty-string print failure.

A round trip compares the normalized logical token stream and ordered property graph; it does not require preservation of source text which the selected writer explicitly normalizes.

Save fault injection

Inject failure before open, after header character n, before/after every message, during epsilon encode, during close/info/version update, and during each Directory phase. The report MUST distinguish:

• bytes/characters accepted by the external stream;
• last complete logical record and message;
• current adapter saving state;
• buffer status and dirty ticks;
• external file/version/member identities; and
• retry, skip, abort and cleanup results.

Cross-profile differential tests

At minimum, run the same synthetic corpus through both profiles and assert these differences rather than merely allowing them: