Session Date/Time: 07 Nov 2025 14:30

CBOR

Summary

The CBOR working group session at IETF-124 primarily focused on ongoing discussions around serialization, determinism, and the status of the "Common Deterministic Encoding" (CDE) document. There was significant debate regarding the necessity and implications of defining different serialization profiles beyond existing deterministic encodings, specifically "ordinary serialization" which introduces definite lengths as a requirement. Updates were also provided on the EDN Literals and Pact (Prefix Aggregate CBOR Tags) drafts, with both showing progress towards resolution.

Key Discussion Points

Introduction and Note Well: Standard IETF procedures and Note Well were covered.
Errata for RFC 8949: An errata concerning NaN equivalence (ensuring sign bits are the same for NaN equivalents) was verified today.
Core H-RF Document: Carsten Bormann noted that the Core H-RF document, now in the RFC Editor Queue, defines cbor:// URI scheme numbers and registers the cpa99 CBOR tag, relevant to the working group's scope.
Serialization and Determinism (Lawrence's Discussion Points):
- Lawrence emphasized RFC 8949 issues, including preferred serialization lacking requirements, shortest length encoding of NaNs, unification of big numbers and integers, lack of clarity in determinism definitions, modifications to the data model in section 3.4.3, NaN equivalence, and duplicate detection.
- Scope of "Common Deterministic Encoding" (CDE): Carsten Bormann clarified that CDE was intended as a separate explainer/best practice document, not a revision of RFC 8949, akin to JWT's BCP 225.
- Rohan pointed out that the discussion should first establish what implementers need before deciding how to document it (e.g., RFC update, BCP, errata). He noted a clear consensus that previous approaches were not entirely effective.
- Bill Beltrum, from an implementer's perspective, indicated that the current ecosystem is "in shambles" and suggested normative changes might require a "CBOR 2" document rather than just informational advice. He strongly advocated for test vectors as the "lingua franca" for implementations.
- Lawrence presented his draft which defines two new standards track serializations: "ordinary serialization" (like preferred but with definite length as a requirement) and "deterministic serialization" (ordinary + map key sorting), rather than directly updating RFC 8949.
- Proposed "Menu" of Encoding Choices:
  - Carsten Bormann outlined four existing choices:
    1. "Well-known CBOR" (general, anything legal per RFC 8949).
    2. "Legacy deterministic encoding" (from RFC 7049).
    3. "Recommended deterministic encoding" (what RFC 8949 intended for common deterministic encoding, aka CDE).
    4. "Definite Length Only" (DLO).
  - He argued against adding "ordinary serialization" as a separate interoperability constraint, citing concerns about fragilizing CBOR by making unnecessary requirements on decoders and uncovering bugs in partial implementations. He stressed separating data model constraints from encoding constraints.
- Arguments for "Ordinary Serialization":
  - Rohan, Joe, and Chris Lemons (representing CoAP profiles) strongly advocated for formally defining "ordinary serialization" or a similar concept. They noted that:
    - Application-layer protocols often need to mandate specific encoding choices (e.g., definite length) for interoperability, security (avoiding indefinite length abuse), or to simplify implementations.
    - Such restrictions are not "forking CBOR" but defining profiles.
    - "Ordinary serialization" as proposed by Lawrence provides clear, specific terminology for these profiles, simplifying library development and enabling gradual transitions for existing deployments.
    - Chris Lemons explicitly stated his CoAP profile would replace existing text with a reference to "ordinary serialization" if available.
- Poll on Lawrence's Draft: A poll was taken asking, "Is Lawrence's draft going in the direction we want a serialization draft to go?" The results were roughly evenly split between "Yes" and "No Opinion." A follow-up poll asked, "Are you okay with the choices of general, ordinary, and deterministic?" This also showed varied opinions, with some needing to read the draft.
- The sense of those present indicated that this framing of serialization choices (general, ordinary, deterministic) is useful to a majority of participants, warranting further discussion.
EDN Literals:
- Carsten Bormann identified the EDN Literal document as close to completion, with other documents waiting on it.
- Joe and Carsten reported convergence on raw strings, which avoid JSON-style escaping "hell," with only one outstanding sticking point between them. They committed to prioritizing its resolution.
- An interim meeting for discussion was suggested before Christmas.
Pact (Prefix Aggregate CBOR Tags):
- The draft (dash-17) has incorporated recent implementation feedback.
- Changes include tunables for compactness (A=12, B=8, C=8), addressing the "map key trap" for error messages (changing from 1-1-1 of undefined to 1-1-1-2 of any), and adding guide rails with security considerations for table setup definitions.
- As Pact defines infrastructure for specific applications, Carsten proposed setting up unofficial high-bandwidth web calls among interested parties to resolve remaining dissent rather than an official interim.

Decisions and Action Items

The errata for RFC 8949 concerning NaN equivalence (sign bit) has been verified.
Joe and Carsten will prioritize resolving the single outstanding issue in the EDN Literals draft, aiming for a resolution before Christmas.
Interested parties in the Pact draft are encouraged to organize unofficial high-bandwidth web calls to resolve remaining dissent.

Next Steps

Continue the discussion on serialization and determinism on the mailing list, focusing on the proposed framing of choices (general, ordinary, deterministic).
Joe and Carsten to finalize the EDN Literals draft, with a potential interim discussion before Christmas if needed.
Unofficial calls for Pact to be organized by interested implementers.
The next scheduled interim call is December 10th, dependent on agenda items.
The next IETF meeting (IETF-125) will be held in Shenzhen.