**Session Date/Time:** 08 Mar 2023 15:00

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

## Summary

The CBOR working group meeting began with an informal "hallway discussion" due to the chairs' delayed arrival, focusing on a presentation of the CDDL 2.0 module structure. Key feedback on map composability and the "socket" concept for extending maps was discussed. The official meeting covered the status of the Time Tag draft and a comprehensive proposed roadmap for CDDL 2.0, including immediate grammar fixes (CDDL 1.1), additional control operators, the module system, and future work on annotations. Discussions also touched upon collecting CDDL models, application-specific literals, and process for IANA number allocation. The proposed CDDL 2.0 roadmap received general support. The meeting concluded with a brief overview of the Deterministic CBOR (DC-BOR) work by Blockchain Commons.

## Key Discussion Points

*   **Initial Hallway Discussion:** The meeting started informally for the first 30 minutes due to the chairs' delayed arrival. This time was used for an early discussion on CDDL 2.0.
*   **CDDL 2.0 Module Structure Presentation:**
    *   A presentation showcased the implemented module structure for CDDL 2.0, focusing on `include` (for local files) and `import` (for libraries).
    *   Objectives included constructing CDDL from multiple files and using existing CDDL as a library.
    *   Features demonstrated included namespacing imports (e.g., `import RFCxxxx as cozy`) to avoid name conflicts and limiting imports to specific names using a `from` clause (e.g., `import label, values from RFCxxxx`).
    *   The tool supports recursive copying of dependencies and automatic aliasing of imported names to be accessible in the current namespace.
    *   Command-line import/include options (`-I`, `-i`) were shown for quick extraction of specific rules and their dependencies.
*   **Feedback on CDDL Module Structure:**
    *   A participant (Chris) found the capabilities useful, covering needs observed in other languages.
    *   Chris raised a related challenge regarding the composability of maps, specifically how to define new keys and values for an existing object in a clear way, noting the current use of "crutches" like `* cozy-label => cozy-values`. The concept of "sockets" was mentioned as a potential solution for composing maps from different library sources.
    *   The idea of an `RFC cddl models` draft was introduced, aiming to collect and integrate models from existing RFCs, making them more reusable and adding "sockets" where beneficial.
    *   The issue of referencing registered components defined in drafts (e.g., the `Coordinate Reference System tag`) and the challenges of evolving them when the original registrant is unresponsive was discussed.
*   **Time Tag Status (`draft-ietf-cbor-time-tag`):**
    *   The document is largely complete but has incomplete CDDL.
    *   Its progress is currently blocked by the `sedate` draft, which is with the IESG.
    *   The working group will hold off on submission until the `sedate` situation clarifies, to avoid having the IESG resolve dependencies.
    *   No immediate documents are critically blocked by Time Tag, though proposals for signed timestamps (e.g., for RATS) exist.
    *   The item was slated for discussion at IETF 116.
*   **CDDL 2.0 Roadmap Discussion:** A phased plan for CDDL evolution was proposed:
    *   **CDDL 1.1 (Short Term - before IETF 117):**
        *   Grammar fixes, including non-literal tags (which are proving important) and allowing empty files (useful in the CDDL 2.0 environment). These are considered fixes and minor additions, not sweeping changes.
    *   **More Control Operators (Short Term - bundled with 1.1):**
        *   A separate draft (`draft-greevenbosch-cbor-more-control`) defines useful control operators (e.g., for base64 encoding) that complement existing CDDL and have precedents (`RFC9165`).
    *   **CDDL 2.0 Modules (Medium Term - before IETF 118):**
        *   Building on the demonstrated module system, this is an "actually doing it" phase, with implementation ongoing.
        *   Further work on composability (e.g., map sockets) may extend this timeline slightly.
    *   **Annotations (Longer Term):**
        *   Future work item, with preliminary ideas including drawing inspiration from Relax NG annotations and integrating co-occurrence constraints (like Schematron) and JSON Path.
*   **Not-So-Mainline CDDL Discussions (Informational/Future Work):**
    *   **CDDL in JSON Format:** Agreeing on a JSON representation of CDDL for tool interchange, building on existing CDisc formats. This would be an informational document.
    *   **Collecting CDDL Models from RFCs:** Creating a collection of referenceable models from existing RFCs (e.g., an `RFC cddl models` draft). The idea of a `cddlcatalog.org` was brainstormed, similar to `yangcatalog.org`, to provide a widely accessible infrastructure.
    *   **Application-Specific Literals:** An extensible way to include application-specific literals within CDDL, potentially leveraging ideas from extended diagnostic notation.
    *   **Process for Number Space Allocation:** A document describing a useful process for dealing with IANA number space allocations during draft development. This might not be published as an RFC but serves as a guide.
    *   **CDDL for CSV:** Exploring the use of CDDL for describing CSV tables, citing an example with the CoRE SID format.
*   **Draft-Numbers Discussion:** A participant (Marco) raised a point about extending the `draft-ietf-cbor-draft-numbers` concept from map keys to map values, especially for enumerations, noting this is more complex.
*   **Deterministic CBOR (DC-BOR) Introduction:**
    *   Waldo (Blockchain Commons) joined late due to a time zone miscommunication and provided a quick overview of DC-BOR.
    *   Blockchain Commons uses CBOR for stable data serialization in blockchain and cryptographic contexts (e.g., hashing, signing, encrypting), where data stability is critical.
    *   DC-BOR aims to tighten up "loose ends" in the existing deterministic CBOR specification, focusing on requirements for codecs (e.g., ordered map keys) and best practices for developers.
    *   DC-BOR is not a new dialect but a set of requirements for CBOR codecs; all DC-BOR is valid CBOR, but not all CBOR is valid DC-BOR.
    *   A new internet-draft is expected to be published shortly, along with Rust and Swift implementations and related YouTube videos.

## Decisions and Action Items

*   **CDDL 2.0 Roadmap:** A sense of those present indicated support for the proposed CDDL 2.0 roadmap (CDDL 1.1, More Control Operators, CDDL 2.0 Modules, Annotations, and informational items).
*   **Time Tag for IETF 116:** The `draft-ietf-cbor-time-tag` will be added to the IETF 116 agenda for further discussion, especially concerning its dependency on `sedate`.
*   **CDDL 2.0 for IETF 116:** Key items from the CDDL 2.0 roadmap, specifically the Modules part and Annotations, will be prioritized for discussion at IETF 116 with the goal of working group adoption. The `draft-ietf-cbor-draft-numbers` document was also suggested for discussion. Grammar fixes and control operators might be handled primarily on the mailing list.
*   **Coordinate Reference System Tag:** Efforts will continue to find the original registrant of the `Coordinate Reference System tag`. If unsuccessful, the work may be used as input for a new draft.
*   **DC-BOR Draft Review:** The working group anticipates the publication of a new internet-draft on Deterministic CBOR by Blockchain Commons for review.

## Next Steps

*   The chairs will coordinate the IETF 116 agenda to include Time Tag, CDDL 2.0 Modules, Annotations, and potentially the `draft-ietf-cbor-draft-numbers` for working group discussion and adoption.
*   Continue work on the CDDL 1.1 grammar fixes and control operators, aiming for mailing list progression unless major issues arise.
*   Review the upcoming Deterministic CBOR internet-draft from Blockchain Commons.
*   Explore the feasibility of a `cddlcatalog.org` for collecting and making CDDL models referenceable.