Appendix B — REP-0001: The registry core

Summary

The design restated as something an implementer works from, borrowing Python's enhancement-proposal format for the sections it forces: Security Implications, How to Teach This, Rejected Ideas and Open Issues are required, not optional, and three of the four are where this design has most to say. Everything normative in documents 01–03 and 11–13 is collected with RFC 2119 keywords and every recorded corrective applied, which makes it the one place in the pack where the schemas are current rather than superseded-with-a-note. Its Status is Draft and its Sponsor field is empty — PEP 1 requires a champion, and the gap is accurate rather than an omission.

Key concepts

• The ownership rule, normatively — a valid signature by a non-owner MUST NOT be write authority — 2019 reproduced exactly if you check one and not the other
• Eleven rejected ideas — the section to read before proposing an improvement
• Read the fixture flag before the signature — a fixture's signatures verify and prove nothing
• Teachability as a definition of done — if a fresh session cannot complete the walk from the page alone, the spec is not finished

Key ideas

• The pack's decisions register is a Status field that has not been formalised yet.
• A REP can never move past Draft while there is no accepting authority — which is the honest state, not a gap to paper over.
• PEPs are CC0; this is CC BY 4.0, and the deviation is stated rather than made quietly.
• One REP for six separately contestable ideas is against PEP practice, and it should split the moment any one of them is contested.

Read the document