**Session Date/Time:** 26 Jun 2024 14:00

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

## Summary

The CBOR Working Group meeting primarily focused on the status of various drafts, with a significant portion dedicated to `draft-ietf-cbor-edn-literals`. Key discussions included the document's title, its informational status despite normative ABNF, the structure of its ABNF (single-pass vs. layered), and a proposed change to allow optional commas by replacing implicit string concatenation with an explicit operator. The meeting also touched upon a CBOR tag allocation request for D-CORE and plans for the upcoming IETF meeting in Vancouver.

## Key Discussion Points

### Document Status Updates

*   **draft-ietf-cbor-time-tag (RFC 9585)**: This document has completed its second IETF Last Call (concluded this morning) and is currently in ISG status, awaiting AD approval (a "button press" by Francesca) to be moved to the RFC Editor queue. No further working group action is required.
*   **draft-ietf-cbor-cddl-grammar-update (RFC 9586)**: The update to the CDDL grammar has been approved. A revised ID (`-06`) incorporating GitHub PRs has been committed. It is now awaiting AD verification and processing.
*   **draft-ietf-cbor-ef-update**: This document has been adopted as a working group item following positive feedback from multiple individuals during the adoption phase.

### Extended Diagnostic Notation (EDN) Literals (draft-ietf-cbor-edn-literals)

*   **IETF Last Call Status**: The document completed its IETF Last Call based on `-09` and is now awaiting AD go-ahead, with a revised ID (`-10`) currently being prepared.
*   **Outstanding Pull Requests**: Five pull requests are ready to be merged, addressing comments from the IETF Last Call. These cover security considerations, error handling guidance for tag 999, clearer text for encoding indicators, usage of long numbers, and a minor typo. Some reviews are still pending for these PRs.
*   **Title Discussion**:
    *   The current title, "CBOR Extended Diagnostic Notation (EDN) Application-Oriented Literals, ABNF, and Media Type," was noted as long-winded and obscure.
    *   Suggestions for a more concise and comprehensive title were raised, such as "EDN Update" or "Comprehensive Diagnostic Notation for CBOR," reflecting that it consolidates various aspects of EDN.
    *   A sense of those present indicated that now is the appropriate time to address the title change before final publication.
*   **Informational vs. Standards Track**:
    *   A question was raised regarding the document's informational status, given that it includes a normative ABNF appendix (Appendix A).
    *   It was clarified that while the ABNF is normative in the sense that it defines valid EDN instances, the document itself is informational because EDN is not primarily an interchange format. Its primary use is for examples, specifications, and tool interfaces. Informational documents can contain normative sections for parts that users *must* be compatible with if they use that part of the specification.
*   **ABNF Structure (Single-Pass vs. Layered)**:
    *   A proposal by Goan Mai suggests replacing the current layered (two-pass) ABNF with a single-pass ABNF.
    *   Arguments against a single-pass ABNF were presented: modern parser generators find the dual-pass mechanism simpler to implement, merging layers introduces complexity and risk of errors, and new application-oriented literals would require more work to integrate.
    *   The current layered approach allows implementers to create their own single-pass ABNF if desired, and such an alternative could be provided in a separate reference (e.g., GitHub repository or Wiki).
    *   There was no strong support in the discussion for adopting the single-pass ABNF within the main document.
*   **Implicit String Concatenation and Optional Commas**:
    *   **Current State**: RFC 8610, Appendix G4, defines implicit string concatenation in EDN (e.g., `"foo""bar"` results in `"foobar"`). This feature has seen very limited implementation or use.
    *   **Proposal**: Replace implicit string concatenation with an explicit operator (e.g., `+`) to allow commas to be optional in EDN sequences, arrays, maps, and stream strings.
    *   **Upsides**:
        *   Addresses a frequent request from users for optional commas (evidenced by RFC 9529 and other drafts omitting commas).
        *   Aligns EDN with CDDL, where commas are already optional.
        *   The implicit concatenation feature is rarely used, minimizing impact.
    *   **Downsides**:
        *   This is a non-backwards compatible change that could alter the meaning of existing examples (e.g., `["a" "b"]` would change from a single string "ab" to an array of two strings "a", "b"). This change might not lead to an error message, which is considered "ugly."
        *   Cosmetic impact on new notation like ellipses (e.g., `s"+..."` instead of `s"..."`).
    *   **Operator Choice**: The `+` character was proposed as the explicit concatenation operator, citing its common use in other languages and precedent in YANG.
    *   **Working Group Sentiment**: A poll of the room was taken to gauge opinion on moving forward with this change. While the ultimate decision for an additional IETF Last Call rests with the AD, the discussion indicated a strong desire to make commas optional.

### CBOR Tag Allocation (D-CORE)

*   **Request**: A request for a CBOR tag allocation was received from D-CORE. The tag would describe a "leave" (or "any") element within an envelope structure that uses alternatives (e.g., map, list, or any type).
*   **Discussion**: The discussion explored the potential for a more general-purpose tag that signifies an "escape" from a top-level structure into an embedded, differently interpreted element. This pattern is common, often handled by embedding CBOR in byte strings.
*   **Decision**: The designated expert (chair) will accept the specific 2011 tag request for D-CORE. The idea of a more general-purpose "escape" tag will be kept on the "stove" for future consideration, as D-CORE's request also involves additional specific semantics.

## Decisions and Action Items

*   **EDN Literals - Title**: A new pull request will be created to propose a more concise and comprehensive title for `draft-ietf-cbor-edn-literals`.
*   **EDN Literals - Implicit Concatenation/Optional Commas**: A pull request will be created to implement the change to an explicit concatenation operator (likely `+`) and enable optional commas. Text will also need to be inserted in several places to describe this change.
*   **CBOR Tag Allocation**: The expert will accept the 2011 tag request from D-CORE.
*   **Future General-Purpose Tag**: The concept of a general-purpose "escape" tag for embedded structures will be retained for future discussion and potential development.

## Next Steps

*   Merge the five pending pull requests for `draft-ietf-cbor-edn-literals`.
*   Submit `draft-ietf-cbor-edn-literals-10` as a revised ID incorporating the title change and the implicit concatenation/optional comma change. The AD will then decide whether to move directly to ISG ballot or conduct another IETF Last Call.
*   The working group will meet at IETF 120 in Vancouver. A call for agenda items will be issued soon, with participants encouraged to add items to the minutes of the next interim meeting (scheduled in two weeks) for final agenda planning.
*   An additional meeting for related CBOR/COAP work (CoVID) will occur immediately following this session.