# 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:
```diff
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.