3.4 Extension and Conformance
3.4.1 Extension #
A chapter specifying a wire format, a file format, or a protocol SHOULD close with an extension article stating how the thing may grow.
An extension article SHOULD distinguish:
- Additive changes, which an implementation of the current version can ignore safely — a new optional field, a new entry in an open-ended set.
- Changes requiring a version bump, which it cannot — a new required field, a new value in a closed enumeration, any change to an algorithm the format has frozen.
- Reserved space, where the format deliberately leaves room, and what an implementation does when it encounters a value there.
A specification MUST state, for every enumeration it defines, whether that enumeration is closed. An implementation cannot decide whether to ignore or reject an unknown value without being told.
3.4.2 Conformance #
A chapter SHOULD close with a conformance article summarising, per role (§3.2), what that role must do. The article is a summary and MUST NOT introduce a requirement stated nowhere else.
A conformance article SHOULD also state plainly what conformance does not require. A reader who has just been given a list of obligations benefits more from knowing where their freedom lies than from a longer list.