RFC-0009: Compatibility Policy

Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com

Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.

Abstract

This document defines the compatibility policy of the Untilum Protocol, organized around one rule: creation may be deprecated, opening never is. It specifies protocol versioning, fail-closed reader rules and conservative writer rules, the requirement that every version’s published test vectors stay green forever, the SDK-to-protocol support matrix in which opening support only ever accretes, and the documents-as-last-resort guarantee for century-scale openability.

1. The one rule everything else serves

Creation may be deprecated. Opening never is.

A capsule is a promise with a 50–100 year maturity. Any implementation that could ever create or open protocol version N MUST keep opening version N for as long as it exists, in every subsequent release. There is no sunset clause for opening — deprecation, in this protocol, only ever means “stop making these”.

2. Protocol versioning

• A capsule’s v field is its protocol major version — an integer, present in every capsule, first field checked by every parser. The capsule is self-describing; there is no runtime negotiation (an offline artifact has nobody to negotiate with).
• Major (v1 → v2): any change to the wire format’s mandatory surface. New majors come only via the RFC process (RFC-0008 §4).
• Minor (v1 → v1.1, e.g. encrypted metadata): purely additive, older openers of the same major must still open new-minor capsules or fail with a clear versioned error — never silent misparse.
• Current versions: v1 (stable wire format, the default for creation and opening — capsule-v1.md), v2 (Draft — tsp-v1.md §10.1; creatable only behind explicit opt-in until its RFC is Accepted).

3. Reader rules (openers and verifiers)

• R1 — An unknown major version MUST be rejected with an error naming both the capsule’s version and the versions supported. Never attempt best-effort parsing of a future major.
• R2 — Within a supported major, unknown top-level fields MUST be rejected (the existing anti-smuggling rule) — additive evolution happens through new minors that define their fields, not through readers tolerating mystery data.
• R3 — Unknown beacon types, identity types, KDFs, or algorithm identifiers fail closed (RFC-0005 §3, RFC-0007 §R2).
• R4 — Every supported version keeps its published test vectors green in CI forever. A vector that stops passing is a release blocker, not a flaky test.

4. Writer rules (creators)

• W1 — Default to the newest Accepted protocol version; never silently produce a Draft version.
• W2 — When a version’s creation is deprecated, implementations warn for ≥ 12 months before removing creation support. Opening support is untouched (§1).
• W3 — A writer MUST NOT emit fields the target version does not define (a v1 capsule with v2 fields is invalid under R2, by design).

5. SDK ↔ protocol support matrix

SDK majors declare their protocol support explicitly; the standing shape:

SDK 0.x (current) ──creates──→ Protocol v1 (default), v2 (opt-in draft)
                  ──opens────→ Protocol v1, v2

SDK 1.x           ──creates──→ Protocol v2 (default), v1 (deprecated path)
                  ──opens────→ Protocol v1, v2

SDK 2.x (future)  ──creates──→ Protocol v3 (default), v2
                  ──opens────→ Protocol v1, v2, v3      ← opening only accretes

The invariant across every row: the “opens” list only ever grows. An SDK major may drop creation of old versions after the W2 window; it may never drop opening. Each SDK release documents its matrix in the package README and asserts it in tests.

6. The last-resort compatibility layer

Version support in software is necessary but not sufficient for a century: the terminal fallback is that every protocol version’s documents (spec + RFCs + test vectors) are complete enough to re-implement an opener from scratch, and the offline decryptor for each version is self-contained and archived alongside capsules. Compatibility policy governs the living implementations; the documents guarantee the dead ones can be resurrected.

7. Security Considerations

The fail-closed reader rules (R1–R3) are anti-downgrade and anti-smuggling mechanisms: best-effort parsing of unknown majors, tolerated mystery fields, or best-guess handling of unknown algorithms would each reopen the crafted-input surface closed by RFC-0002 §T9. R4 (vectors green forever) guards against silent cryptographic regressions across releases. The one rule of §1 protects availability (RFC-0002, asset A4): removing opening support for a released version would convert every surviving capsule of that version into a loss.

8. References

8.1. Normative

• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
• [RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
• [CAPSULE-V1] “Capsule v1 — wire format”, ../spec/capsule-v1.md.
• [TSP-V1] “Untilum Protocol (TSP) — Version 1”, ../spec/tsp-v1.md — §10.1 the v2 draft.

8.2. Informative

• RFC-0008 Governance — this series.

Editors’ Addresses

Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues

Revision History

Date	Status	Change
2026-07-07	Draft	Initial version.
2026-07-17	Last Call	Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added; no normative changes. Entered Last Call per RFC-0008 §4.