**Session Date/Time:** 03 Sep 2025 14:00

# [CBOR](../wg/cbor.html)

## Summary

The CBOR working group discussed the various layers of CBOR serialization, from the most permissive ("well-formed") to fully deterministic. A key point of discussion was the naming and understanding of these layers, particularly the distinction between serialization variation (intentional in CBOR for constrained environments) and data model variation (which is protocol-specific). Participants debated the clarity of existing terminology in RFC8949 and the potential benefits and drawbacks of introducing new names or clarifying existing ones.

## Key Discussion Points

*   **CBOR Serialization Layers:** Lawrence presented a model illustrating three additive layers of restriction on CBOR serialization:
    *   **Bottom Layer (Variable):** Represents the most permissive CBOR encoding, intentionally allowing variability for constrained environments (e.g., optional map sorting, indefinite lengths for streaming, non-shortest length encodings). Participants noted this layer lacks a clear normative name, with "generic decoder" or "well-formed CBOR" suggested during discussion.
    *   **Preferred Serialization (RFC8949 Section 4.1):** Requires shortest length encoding for integers and floats, has ambiguity regarding NaNs, expresses a *preference* for definite lengths, and requires unification of the number space for integers and big numbers.
    *   **Basic Serialization (draft-ietf-cbor-cde):** Adds definite length as a *requirement* (stronger than "preference" in Preferred).
    *   **Top Layer (Full Determinism):** Achieves full determinism by adding map sorting to the Basic serialization requirements, eliminating all serialization variation.

*   **Naming the Most Variable Layer:** A significant part of the discussion focused on the bottom, most variable layer.
    *   It was agreed that this layer needs a clear name to facilitate discussion.
    *   The term "generic decoder" has been informally used but was considered an implementation detail rather than a protocol description.
    *   "Well-formed CBOR" (a term from RFC8949) was proposed and found to be semantically correct, as it implies validity while allowing all forms of variability (e.g., different length encodings, definite/indefinite lengths), but still disallowing invalid structures like additional information 28.

*   **Interoperability and Profiling:**
    *   It was clarified that if a protocol references RFC8949 for CBOR but does *not* specify any serialization profile, a receiver must implement the *entire* range of CBOR capabilities described in RFC8949, including indefinite lengths and all valid length encodings.
    *   To restrict receiver implementations (e.g., to not require streaming support), a protocol must explicitly *profile* RFC8949.

*   **Serialization Variation vs. Data Model Variation:**
    *   Lawrence highlighted the critical distinction between serialization variation (how data is encoded in CBOR, which is intentionally variable in base CBOR) and data model variation (when a protocol allows multiple data types or representations for a single semantic value, e.g., a temperature as an integer or a float).
    *   Serialization variation, when unconstrained, prevents determinism in CBOR.
    *   Data model variation is not exclusive to CBOR and also leads to a loss of determinism in any data format if not addressed by the protocol itself.
    *   The "unification of integer and big number spaces" in Preferred serialization was noted as a data model-level operation, creating an artificial equivalence class for serialization rather than a pure serialization variation.

*   **Terminology and Renaming:**
    *   Concerns were raised about the clarity of current names like "Preferred" and "Basic," with suggestions that names like "shortest length," "definite length," or "sorted" might be more descriptive.
    *   The prospect of renaming existing terms from RFC8949 was discussed. While some felt it could improve clarity, others expressed strong reservations due to the large number of existing RFCs, drafts, and external standards bodies that reference and rely on the current RFC8949 terminology, fearing it could cause significant confusion and implementation issues.
    *   A suggestion was made to add a detailed terminology section to a future document (e.g., the CDE draft) to clarify existing RFC8949 names and potentially note what better alternative names might have been, without formally changing the normative names.

## Decisions and Action Items

*   **Lawrence:** Will post a summary of this discussion to the working group mailing list, highlighting what was discussed and what still needs further input from more participants.
*   **Lawrence:** Will provide the slide deck to the Chair in a correct, displayable format for posting to the meeting materials.

## Next Steps

*   Further discussion is needed on clarifying the terminology used for CBOR serialization layers, possibly by adding a dedicated terminology section to a relevant draft (e.g., `draft-ietf-cbor-cde`).
*   The group will continue to assess the clarity and impact of current serialization layer names in RFC8949 versus potential alternative or supplementary descriptive terms.