Erratum — draft-fossil-sparse-cone-00 §3.1

Document	draft-fossil-sparse-cone-00
Section	3.1 — Location and Mutability (what a cone may contain, and how a reader that does not understand it must behave)
Type	Technical (the serialization has a version but the text never says what an unknown version means)
Status	Applied in draft-fossil-sparse-cone-00 (2026-10-17)
Reported	2026-10-17
Submitter	Dan Mestas
Found via	Specifying the horizon member of draft-fossil-horizon-00 as a member of the cone

1. Summary

§3 defines a cone as a set of path-prefix members. §3.3 notes that exclusions leave "the canonical sorted serialization and the digest" unchanged, which is the only place the text acknowledges that the serialized form is versioned. draft-fossil-horizon-00 adds a member that is not a path prefix. The text gives no rule for a member of another kind and no rule for a reader that meets a serialization version it does not know. An implementation written from the text could read a versioned form's lead-in bytes as a member count and misclassify every path.

2. Location

§3.1, after the paragraph ending "A cone MAY be widened or narrowed at any time (Section 5.4)."

3. The reference behavior

The reference implementation's canonical form has no version byte for a cone of path inclusions only: its first byte is a nonzero member count. A cone with exclusions is written with a 0x00 lead-in, impossible as a v1 count, followed by a version byte and then the count. The parser refuses a 0x00 lead-in whose version byte it does not recognize. So the refusal already exists; the text does not require it, and does not say what a refused cone means for the store.

4. Impact

Observable. A reader that accepts a cone of an unknown version and treats its bytes as path members classifies wrongly and silently. A reader that refuses but treats refusal as damage reports a healthy store as broken, which §5.2 forbids for every other policy-loss case.

5. Correction

§3.1, new final paragraph:

    MAY hold different cones.  A cone MAY be widened or narrowed at any
    time (Section 5.4).
+
+   A cone MAY carry members of kinds other than path prefixes, each
+   defined by another document; the horizon member of draft-fossil-
+   horizon is one.  The canonical serialization MUST mark a cone
+   carrying any such member with a version distinct from that of a cone
+   carrying only path members, and an implementation that does not
+   understand the version MUST refuse the cone rather than read it as
+   path members.  Refusal is policy loss (Section 5.2): the store heals
+   toward dense.

6. Rationale

Puts the extension point where a reader learns what a cone is, states the one invariant other documents need (a distinct version per new member kind), and ties refusal to the §5.2 rule so that an old implementation meeting a new cone degrades to dense instead of misreading or reporting damage. MUST rather than SHOULD because a misread cone is silent misclassification, the failure this document exists to prevent.

7. Verification

• Source: the cone serializer and parser in the reference implementation; the parser's unknown-version branch returns an invalid-member error.
• Dependent text: draft-fossil-horizon-00 §3.3 requires a distinct version for a cone carrying a horizon member and cites this section for the serialization it extends.