Session Date/Time: 10 Jan 2024 15:00

CBOR

Summary

The CBOR Working Group held an interim meeting to discuss the status of various documents, particularly focusing on the progression of Deterministic CBOR Encoding (CDE) and Deterministic CBOR (D-CBOR). Key discussions revolved around the controversial handling of NaN payloads within CDE, the appropriate document track for both CDE and D-CBOR (Standards Track, BCP, or Informational), and future work on CDDL modules, Yang CBOR, and structured data with elision (Gordian envelope).

Key Discussion Points

Document Status Updates:
- CBOR Tags (1011, 1012, 1013 for datetime): Currently in the RFC Editor queue; tags are allocated and ready for use.
- CDDL 2.0 (Grammar Fixes and Extended Diagnostic Notation): Passed Working Group Last Call (WGLC) and is ready for submission to the IESG. Minor clarifications were added after a thorough shepherd's review.
- CBOR Packed: Draft version d10 was submitted, containing editorial and minor fixes with no technical content changes. Validation efforts are ongoing, with an aim to complete implementation feedback and submit to the IESG by the end of February, potentially after a second WGLC. Discussion about implicit/incremental table setup and its interaction with deterministic encoding will continue but may not impact this document directly.
- CDDL More Control: The document has gained a "printf" operator, which requires further specification beyond just pointing to POSIX/ISO 9899.
- CDDL Modules Concept: Already in use covertly in some places, but broader adoption awaits further document advancement.
- Interim Meeting for CDDL 2.0: A dedicated interim meeting focused on CDDL 2.0 use, including "More Control" operators and the "Modules" concept, needs to be planned before the Brisbane IETF meeting.
Deterministic CBOR Encoding (CDE):
- An update to the CDE document was recently submitted, with general agreement to advance it soon to address questions about deterministic encoding.
- Security Considerations: The existing security considerations section needs further development beyond its current single paragraph.
- NaN Payloads: The primary discussion point was the handling of NaN payloads, a "forgotten stepchild" of IEEE 754.
  - Current Draft: Adds guidance on handling NaNs with payloads, aligning with IEEE 754-2019.
  - Arguments Against Supporting NaN Payloads in CDE (Lawrence):
    - Programming environments generally do not support NaN payloads, making implementation difficult (e.g., C/C++ requires bit shifts; no standard library access).
    - Lack of clear end-to-end use cases for NaN payloads.
    - To maintain a "tight specification" for CDE, it should avoid "dusty corners."
    - CDE is not obligated to support all of CBOR; if NaN payloads are needed, users can opt out of CDE.
  - Arguments For Supporting NaN Payloads in CDE (Carsten):
    - CDE should not deprecate a feature of CBOR; the original CBOR specification already defines them.
    - Defining deterministic handling is feasible and involves minimal code.
    - It's an ecosystem decision to define how to handle existing CBOR features, even if not widely implemented.
    - IEEE 754-2019 (section 9.7) hints at use cases like decorating NaNs with error information (e.g., division by zero).
  - Arguments on Semantic Definition (Wolf, Chris Host):
    - NaN payloads are semantically ill-defined and not generally used as an interchange format, often remaining internal to floating-point implementations.
    - If semantics are undefined, there's no unique way to represent them deterministically.
    - D-CBOR explicitly closes off NaN payloads for this reason.
    - No clear "customer" within the IETF currently asking for this level of detail for floating-point exchange.
  - Proposed Compromise (Carsten): Define an application profile in CDE that relieves users of NaN payload headaches, similar to D-CBOR's approach. This was met with skepticism regarding added complexity from Lawrence.
Deterministic CBOR (D-CBOR):
- Two new revisions have been submitted, simplifying the document by basing it on CDE.
- Document Track Discussion: The working group needs to decide on the appropriate document track: Standards Track (STD), Experimental, Informational, or Independent Submission (Experimental, Informational).
- CDE Dependency: It was noted that D-CBOR is now based on CDE, and CDE's document track is a prior decision that influences D-CBOR's.
  - Carsten stated CDE is intended for Standards Track as it clarifies and enhances RFC 8949's deterministic encoding considerations, serving as a common profile.
  - Arata pointed out that current CDE drafts indicate "Best Current Practice" (BCP), not "Proposed Standard." BCP makes sense for CDE.
- D-CBOR's Purpose: D-CBOR restricts the set of supported data items, serving as a well-thought-out option for applications needing a simpler data model, but not necessarily "the way to do things" for all applications.
- Customer/Use Case (Chris Host): D-CBOR has a customer in the "Gordian envelope" for structured data formats that support "elision," addressing privacy and human rights requirements outlined in existing RFCs. There is interest in CBOR supporting more sophisticated structures like graph data.
- Support for Standards Track (Lawrence, Wolf): Arguments for D-CBOR being Standards Track included its well-defined nature, reasonable use cases, and the benefits of extra review and backing.
- Refinement of Options (Carsten): Carsten noted "Experimental" was inherited from older drafts and is not the current intent for D-CBOR. "BCP" is also unlikely as D-CBOR represents "one current practice" rather than "best current practice." This narrows the choices mainly to Standards Track or Informational.
- Overall Sense: There was good support for D-CBOR being a Working Group document, with discussion focusing on whether it should aim for Standards Track or BCP status.
Future Topics:
- Yang CBOR: Carsten plans to have a draft available by the next interim on how to use CBOR in the context of Yang, particularly where Yang values are typically string-valued.
- Gordian Envelope / Graph Support: This area, supporting graph structures, "elision," and structured data, is a "really big subject." The group should consider modularizing this work so components (like graph support) can be adopted independently. Christopher expressed openness to exploring subsets that fit within the CBOR WG.

Decisions and Action Items

CDE NaN Payloads: Carsten to extract and share use cases for NaN payloads from IEEE 754-2019 section 9.7 (e.g., decorating NaNs with error information) to the mailing list for further discussion.
CDDL 2.0 Use & Modules: An interim meeting is to be planned before the Brisbane IETF meeting, specifically focusing on CDDL 2.0 (including "More Control" operators like "printf" specification) and the "Modules" concept.
CBOR Packed: Validation efforts to continue, targeting submission to the IESG by the end of February.
D-CBOR Document Track: Discussion on the appropriate document track (Standards Track vs. BCP vs. Informational) will continue, with the current sense indicating support for D-CBOR as a Working Group document aiming for STD or BCP.

Next Steps

Continue the discussion on handling NaN payloads in CDE on the mailing list, incorporating the identified use cases.
Plan the dedicated interim meeting for CDDL 2.0, "More Control," and "Modules" before the Brisbane IETF.
Finalize validation and submit the CBOR Packed document to the IESG by the end of February.
Advance D-CBOR as a Working Group document, with ongoing discussion about its normative status (aiming for Standards Track or BCP).
Carsten will prepare a draft on "Yang CBOR" for discussion at a future interim.
Begin discussion on supporting more sophisticated data structures like graphs and "elision" (Gordian envelope), considering modular approaches and how this work fits within the CBOR WG.