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 freezing 31 July 2027. This page is the current list of known items. Please check it before reporting — and note that it holds more than the Open Items appendix inside any published draft, which is only a snapshot taken when that revision was fixed.
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: please open an issue.
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 proposal is to assign bootstrap payload key 6 as an optional, inert text pointer. Measured cost is at most one object row against the Section 8.2.1 ceiling. Open questions: should the value be fixed by the specification or writer-chosen, what should it contain, and is it worth a permanent wire assignment when an implementation change to the existing key 3 achieves much of the same effect at no specification cost? Discuss (#2)
RP-2 · Length and charset bounds on writer-supplied text accepted
Bootstrap keys 3 and 4 are writer-chosen text with no length bound and no charset restriction, in the specification or the reference decoder. A hostile tape can carry arbitrary control bytes in the first human-readable text a diagnostic tool prints. A future draft will bound them and restrict them to printable US-ASCII. No conformant tape is affected. Discuss (#3)
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: unrecognised tape files are classified by elimination and never by reading content, so an embedded document is invisible to a finder who does not already know to look. Discuss (#4)
RP-4 / RO-1 / RE-1 · An independent implementation from the prose alone open · the review we most want
The central claim of these documents is that an implementation built from the text alone reproduces the published conformance vectors. Nobody outside the project has tested it. If you build even a partial reader and it disagrees with the vectors, that disagreement is the most valuable report this window can receive — it is the one class of defect desk review cannot find. Discuss (#5)
Resolved
Nothing yet. Items resolved in a draft revision move here, and that draft's revision history records which items it closed.