RFCs
Requests for Comments
Every change to the standard leaves a written trail
1What an RFC is#
In plain terms: before the standard changes, the change is written down, argued for, and reviewed in public. The document that does this is called an RFC — Request for Comments. Anyone can write one.
A standard is only as trustworthy as its change process. CTXPKG borrows the discipline that served the IETF, Rust and Python well: substantive changes to the specification, the schemas or the registry protocol require a public proposal with motivation, design, compatibility analysis and open questions — before any implementation lands.
Editorial fixes (typos, clarified wording that changes no behavior) do not need an RFC. Everything that could break an implementation does.
2The process#
| Stage | What happens |
|---|---|
| Issue | Open an issue describing the problem — not yet the solution. Maintainers confirm it needs an RFC. |
| Draft | Write the RFC from the template. It gets a number and appears in the index below with status Draft. |
| Review | Public comment period — at least 14 days. Every objection gets a written answer. |
| Decision | Accepted (with rationale), Rejected (with rationale, kept in the index forever), or Withdrawn by the author. |
| Implemented | The spec text changes, the reference implementation follows, conformance vectors are extended if behavior is observable. |
During Phase 1 the maintainers decide; the rationale is always public. From Phase 2 on, decisions move to the steering group — the process itself does not change, only who holds the pen.
3RFC index#
| RFC | Title | Status |
|---|---|---|
0001 | ZIP container format (v2.1) A second, optional container: a ZIP archive carrying manifest, content and binary assets — for packages too large or too rich for a single JSON file. | Draft |
0002 | Provenance attestations (v2.2) Optional, independently signed statements about how a package came to be — source, builder, redaction checks, review — verifiable offline, in the spirit of SLSA and in-toto. | Draft |
Rejected and withdrawn RFCs stay listed — the reasoning behind a "no" is as valuable as the reasoning behind a "yes".
4Writing one#
Start from the template. It is deliberately short — a good RFC is judged by the clarity of its motivation and the honesty of its drawbacks section, not by its length.
curl -O https://ctxpkg.org/rfcs/0000-template.mdSubmit it as an issue or merge request against the standard's repository, or mail it to standard@ctxpkg.org if you prefer. You do not need permission to start — the next number in the sequence is yours.