Session Date/Time: 25 Jun 2025 14:00

CBOR

Summary

The CBOR working group held an interim meeting to address open issues for the CBOR Extended Diagnostic Notation (EDN) document, specifically focusing on the introduction of application literals and the "application sequence" syntax for structured parameters. The discussion covered the document's history, the rationale for supporting structured extensibility beyond simple strings, technical challenges like error message propagation, and the need for compelling use cases. The group decided to proceed with the proposed application sequence syntax, recognizing its foundational role for future extensions and user-friendliness in avoiding complex escaping. Action items were assigned to address error handling and provide further examples, with the goal of submitting an updated draft before the upcoming Internet-Draft deadline and moving towards a Working Group Last Call after the IETF meeting in Madrid.

Key Discussion Points

Document Status and History: The EDN document, originally adopted in 2013, has undergone multiple Working Group Last Calls (WGLC) and received feedback from the IESG. It is currently in "working group last call comment processing." The goal is to prepare it for IESG submission.
Scope of Discussion: The meeting focused on resolving open issues in the existing document, particularly concerning application literals and their sequence syntax. The chairs emphasized avoiding new feature requests or extensive discussions on the broader CDDL ecosystem unless directly relevant to the EDN specification.
Application Literals and Structured Parameters:
- The document aims to provide application-specific extensions to diagnostic notation, allowing descriptive names instead of numeric tags (e.g., decimal(array) instead of 4(array)).
- Previously, application literals were restricted to a single string parameter. The current proposal (introduced in draft -17) extends this to "structural parameters" using a double angle bracket (<<...>>) syntax, allowing multiple, structured arguments. This was identified as a core unresolved issue.
- It was noted that #'foo' is a shortcut for a more verbose structural parameter form, making it easier to parse.
Integrated Grammars: The editor confirmed that a workable solution for integrating extension grammars into the base ABNF of EDN has been found and implemented, making it "bearable" for human use and implementation.
Error Message Propagation (Joe's Blocker):
- A significant blocker for some implementers is ensuring correct error messages for application literals when using a two-layer parsing approach (where the literal's content is parsed by a separate grammar).
- The editor confirmed this is possible by propagating detailed signals (e.g., byte counts) from the Layer 2 grammar back to Layer 1 for proper error message generation.
- The need to generalize this approach for other implementers was raised.
Use Cases for Application Sequences:
- A strong need for compelling, concrete examples demonstrating the clear advantage of application sequences over single-string app literals, without requiring additional new syntax, was expressed. Concerns were raised that without such examples, the new syntax might be introduced and later found insufficient.
- Examples provided during the discussion included:
  - U8<<1, 2, 999, 4223>> as a more readable way to represent tagged arrays (e.g., tag(array(uint8))) than a numeric tag.
  - lang<<"my text", "en-US">> for language tags, avoiding complexities of nested parsing or escaping within a single string.
  - Other potential use cases from the CBOR tag registry, such as sets (tag 2566) and symbols (tag 280), were identified as benefiting from structured parameters.
- The argument was made that app sequences are a foundational step, necessary to support structured data interchange in a way that avoids the tedious and error-prone escaping common in other contexts (e.g., SQL embedded in strings).
Implementation Overhead: While the angle bracket syntax was added late, implementers noted it wasn't excessively difficult to implement, and the associated challenges (e.g., error reporting) are similar to those for single-string app literals.
Future Flexibility: It was discussed that delaying the inclusion of application sequences would likely lead to revisiting the same issues later, suggesting it's better to address this now.

Decisions and Action Items

Decision: The working group will proceed with the proposed application sequence syntax (structural parameters using double angle brackets <<...>>). The general sense was that the benefits of supporting structured data natively in EDN outweigh the remaining concerns, and that this is a necessary foundation for future extensibility and user-friendliness.
Action Item (Karsten): Implement the mechanism for propagating detailed error information (e.g., byte offsets) from Layer 2 application literal grammars to Layer 1 for enhanced error reporting. This is a high priority, with the Madrid hackathon targeted for completion and documentation.
Action Item (Christian): Compile and document more compelling, concrete examples for the use of application sequences, drawing from real-world device annotation use cases and the CBOR tag registry. These examples should clearly illustrate the advantages over appstrings and be included in the document.

Next Steps

The editor (Karsten) will prepare and submit an -18 draft of the EDN document, potentially based on the current editor's copy, with a follow-up -19 draft incorporating discussion outcomes and examples before the Internet-Draft submission deadline (approximately 10 days).
Working group members interested in presenting topics related to CBOR or EDN at the upcoming IETF meeting in Madrid are encouraged to submit their agenda items to the chairs or directly add them to the hedge notes.
The working group will continue its cadence of interim calls.
The overall goal is to finalize outstanding issues during the IETF Madrid meeting and hackathon, with the aim of initiating a Working Group Last Call after Madrid.