Specification review

Open items in the specifications.

The REM-OBJECT, REM-PARITY, and REM-ENCRYPT specifications are review drafts, open for comment until 30 April 2027 and frozen on 31 July 2027. This page is the current list of known items. It holds more than the Open Items appendix inside any published draft, which is only a snapshot taken when that revision was fixed. Please check it before reporting.

How to read this

Each item carries a disposition. Accepted means it will be addressed in a future draft. Deferred means we judge it real but not yet ripe. Declined means we considered it and decided against, with the reason given so the decision can be argued with rather than merely discovered. Comment invited marks the items where outside review would change what we do; those are the best use of your time.

Discussion happens in the linked issues. Anything not listed here is not known to us, so please open an issue.

REM-PARITY generation 2

The development software writes REM-PARITY generation 2, described by the 1.0.0-draft.5 copy in preparation; the published draft.2 text and vector archive describe generation 1. The plain-language account of the split is under the specifications.

Open items

RP-1 · Retrieval pointer on the medium accepted in principle · design open · comment invited

Nothing on a tape says where to obtain the specification that defines it. A finder holds eight magic bytes and must already know what they mean. The generation-2 draft relies on its concept DOI once the format has been identified, but carries no retrieval URI on the medium. Whether the bootstrap should carry one is a wire-format decision that remains open. Discuss (#2)

RP-3 · An embedded copy of the specification on tape deferred · comment invited

Carrying the document itself, rather than a pointer to it, would remove the dependency on any external retrieval path. Deferred because it is a materially larger change, and because it complements a pointer rather than replacing one: a reader recognises tape files by their signatures and treats anything else as opaque, never by reading its contents, so an embedded document is invisible to a finder who does not already know to look for it. Discuss (#4)

RP-4 / RO-1 / RE-1 · An independent implementation from the prose alone open · the review we most want

The project has a separately written Python verifier and an AI-system clean-room recovery exercise, but neither is organizationally outside the project. If you build even a partial reader from the prose and it disagrees with the vectors, that disagreement is the report we most want, because it is the one class of defect that desk review cannot find. Discuss (#5)

TT-3 · Generation-2 physical-media exercise VTL passed · physical open

The one-GiB separation layout has passed clean virtual-tape writes and independent full verification at all three legal block sizes. Supervised physical-tape runs at two block sizes remain open, including observation of the footer, filemark and end-of-data handling, and the drive's early-warning and end-of-medium behaviour. See the gate in the draft.

TT-6 · Terminal-format fuzz plateaus open

Dedicated coverage-guided fuzzing campaigns for terminal replicas, separation extents, and scan walks that reach terminal kinds at all three legal block sizes remain open. The gate requires committed corpus replay and measured plateau reports. See the gate in the draft.

Resolved

RP-2 · Length and charset bounds on writer-supplied text resolved in draft.2

The text now bounds the writer implementation string to printable US-ASCII and the timestamp to RFC 3339 length and syntax, applies the same treatment to the ParityMap fields, and requires safe rendering. Discussion (#3)