**Session Date/Time:** 10 Dec 2025 15:00

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

## Summary

This CBOR interim working group meeting, chaired by Paul Hoffman, focused primarily on the draft-ietf-cbor-serializer document and its associated open issues and pull requests. Key discussions revolved around the naming and clarity of CDDL operators for different serialization types (ordinary, deterministic), the normative intent of appendices, and the general recommendations for CBOR implementers regarding serialization choices. A significant part of the meeting also addressed the handling of Not-a-Number (NAN) values, including a proposal to adopt a separate draft (draft-mcnally-cbor-nan-bister) to provide further guidance.

## Key Discussion Points

*   **CBOR Serialization Document (draft-ietf-cbor-serializer) Updates:**
    *   **Merged Pull Requests (PRs) Review:** Lawrence Lundy presented a review of recently merged PRs:
        *   **CDDL Operators:** Filled in CDDL operators for ordinary (`.ord`, `.ordseq`) and deterministic (`.det`) serialization, including IANA registrations. Acknowledged potential naming conflicts with existing `.dat` and `.ord` and deferred detailed discussion on naming.
        *   **Appendix on Byte String Wrapping:** A non-normative appendix was added to capture previous discussions and rationale.
        *   **Appendix on Checking Decoders:** A non-normative appendix clarified that checking decoders are not a substitute for full input validation, but rather for checking compliance with a serialization scheme.
        *   **Deterministic Encoding of Epoch Date Tag (Tag 1):** A minor clarification was added. Karsten S. questioned if this was specific to deterministic encoding or a general change to tag 1; Lawrence clarified it's a proposed deterministic encoding method for tags, framed as an example in an appendix.
        *   **Sorting Rationale:** A paragraph was added stating that sorting is for determinism, not for application logic or data models. Karsten S. noted that map sorting *can* be useful for structuring application code on constrained devices (e.g., specific key ordering).
    *   **Normative Clarity:** Paul H. (Chair) emphasized the need for clear labeling of normative vs. non-normative text, especially in appendices, to avoid past issues in RFCs. He encouraged participants to propose specific wording changes on the mailing list.
    *   **Consensus Process:** Paul H. reiterated that formal consensus calls should occur on the mailing list, not during interim meetings, due to the limited number of attendees and history of re-litigation. He encouraged individuals to initiate consensus calls on the list.

*   **Handling of NANs:**
    *   **Serialization Draft's NAN Appendix:** A large PR detailed the appendix on non-trivial NANs, minimizing normative text on NANs to only require half-precision quiet NANs. A new subsection clarifies RFC 8949's handling of NANs.
    *   **Proposal for Separate NAN Document:** Discussion centered on adopting draft-mcnally-cbor-nan-bister, which defines a tag for NANs of various lengths (32-bit, 16-bit) to address limitations beyond 64-bit NANs.
        *   Karsten S. acknowledged it addresses a CBOR limitation by extending the data model with a tag, but questioned the strong use case for 32/16-bit NANs. He suggested carrying it forward due to the investment in discussion ("carry home the fruit").
        *   Lawrence Lundy agreed to adopt the document now, seeing it as complementary without conflict, allowing the serialization draft to non-normatively reference it in an appendix.
        *   Paul H. noted that adopting it now, if the draft is well-formed, could prevent further NAN discussions from delaying the serialization document.

*   **Open Issues and Recommendations:**
    *   **Test Vectors:** Plan to include non-conforming test vectors.
    *   **"Ordinary Serialization" Name:** Discussion on finding the right name.
    *   **General Serialization Subsection:** Proposal to add a subsection on "when to use general serialization" to parallel ordinary/deterministic guidance.
    *   **Top-Level Recommendations Section:** Proposal to create a new top-level "recommendations" section.
        *   **Core Recommendation:** "Use ordinary serialization. Deterministic is good too if you're not encoding in a constrained environment."
        *   **"Should" vs. "Recommendation" (RFC 2119):**
            *   Lawrence Lundy intended it as a "should" for authoritative guidance, aiming to standardize current practice for interoperability.
            *   Karsten S. cautioned against using "ordinary serialization" without clear interoperability constraints, arguing it currently combines definite length (interoperability) with efficiency (not strictly interoperability). He stressed being specific about choices future protocol designers can pick up.
            *   Rowan and Joe B. viewed it as a "should" or "best current practice" with clear caveats for when not to follow it, aiming for interoperability.
            *   Martin T. questioned if recommending "ordinary serialization" (which implies definite length) might implicitly disallow indefinite length streaming for some applications.
            *   Paul H. reiterated that recommendations must clarify consequences for interoperability if not followed, especially for implementers with differing constraints.

## Decisions and Action Items

*   **Chair Action:** Discuss with co-chairs the adoption of `draft-mcnally-cbor-nan-bister` by the working group, considering Lawrence Lundy's suggestion for adoption now to allow non-normative referencing from the serialization draft and potentially accelerate its progress.
*   **Editor Action (Lawrence Lundy):**
    *   Address clarity regarding normative intent in appendices and other text for the serialization draft.
    *   Continue work on naming for CDDL operators for ordinary/deterministic serialization.
    *   Further refine wording for the "recommendations" section, clarifying the "should" level of guidance and consequences for interoperability.
    *   Consider adding wording about background and common implementation assumptions/practices, especially concerning preferred vs. ordinary serialization.
*   **WG Participants Action:** Propose specific wording for normativeness/hintiness of sections/paragraphs on the mailing list. Initiate specific consensus calls on the mailing list for contentious topics rather than deferring to interim meetings. Provide wording for instances where implementers might pursue certain optimizations without understanding trade-offs.

## Next Steps

*   Continue discussions on the CBOR mailing list, particularly on the clarity of normative text, the naming of serialization types, and the wording of recommendations.
*   Await a decision from the chairs regarding the adoption of `draft-mcnally-cbor-nan-bister`.
*   Another interim meeting is scheduled for January; the chair will aim for a better-prepared agenda. The chair expressed a strong preference for most WG work and consensus building to occur on the mailing list.