]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

CBOR Working group Internet-Draft The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and RFC 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. About This Document Status information for this document may be found at . Discussion of this document takes place on the cbor Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction (Please see abstract.) Note that the existing extension point can be exercised for new features in parallel to the work described here. forms part of the first set of specifications going forward from the CDDL-2 project together with . The rest of this introduction gives a rough overview over what could be the development plan for CDDL 1.1, 2.0, 2.5.

CDDL 1.1 + 2 plan (standards track) This section is completed. CDDL 1.1 milestone

• "CDDL 1.1": , Grammar fixes: Empty files (enabling CDDL 2), non-literal tags, errata fixes.
• Parallel to CDDL 1.1: More control operators : Additional control operators, another iteration like before.

CDDL 2.0 work:

• Technically complete before IETF 119: CDDL 2.0: (import/include directives, implemented). Feedback is available from IETF 119, one remaining technical issue (sockets).
• Potentially, further directives to be added. No proposals are ripe for specification.

"CDDL 2.5":

• Being prepared: CDDL 2.5: of the present document ("annotations", plus some functionality enabled by that). The requirements are reasonably well-understood; the specific form this takes needs to be worked out. Enables, e.g., (co-occurrence).

Other documents Not on the main line of development, but important ancillary work:

• (Informational, implemented): Section alternative representations of : CDDL-in-JSON format(s) for interchange of CDDL model information between tools.
• (Informational, companion to ): (builds standard collection of referenceable models).
• (BCP? Informational?): (BCP for handling assigned numbers during draft stage; can stay informational as the work described is completed and any reference to the document erased before a specification using it would be published).
• Application-oriented literal e'' makes use of so that diagnostic notation can refer to named numbers that are specified in CDDL. Implemented, see for an introduction.
• Further proposals to improve the integration between CDDL and EDN are likely; see for a work in progress.

More explorative at this point:

• (Standards-Track?) The remaining of this document: application-oriented literals in CDDL mirroring the work in .
• (Informational or Standards-Track?): (using CDDL to model CSV documents).

Important CBOR work that may be reflected in some CDDL extensions:

• Evolving Extended Diagnostic Notation . While EDN and CDDL are independent languages (with EDN rooted in JSON and CDDL in ABNF and Relax-NG), they are often used together, and developments in one may spawn parallel work in the other.
• Common Deterministic Encoding (CDE) and related documents. These do define CDDL operators already, which may be sufficient for initial use; this might be extended once more experience has been gained.
• Packed CBOR . CDDL already can be used to describe the original data item represented in a packed data item. Requirements for describing the latter have not yet been collected; there is some relation to transformation that might need to be explored.

Mending syntax deficits The previous content of this section formed the basis for , except for .

Tag-oriented Literals Incomplete, see .

Processing model: Beyond Validation

Proposal Status:

experiments with implementations ongoing

Compatibility:

backwards compatible

The basic (implicit) processing model for CDDL 1.0 applies a CDDL data model to a data item and returns a Boolean that indicates whether the data item matches that model ("validation"). extends this model with named "features". A validation can indicate which features were used. Validation could also be parameterized with information about what features are allowed to be used, enabling variants (see and for examples).

Annotations The cddl tool () also supports experimental forms of "annotating" a validated data item with information about which rules were used to support validation, currently entirely based on the information that is in a standard CDDL 1.0 data model. This leads to a more general concept of "annotation", where the data model specification supports "annotating" the validated instance by optionally supplying information in the model. (The annotated result is a special case of a "post-schema validation instance" , here one where the data item itself is only augmented, not changed, by the process.) Annotations could in turn provide input to further validation steps, as is often done with Schematron validation in Relax-NG; with an appropriate evaluation language this can be used for checking co-occurrence constraints ().

Transformation Finally, annotations are a first step to transformation, i.e., describing how a validated data item should be interpreted as a transformed data item by performing certain computations. This generally requires even more support from an evaluation language, simple transformations such as adding in default values may not need much support though.

Next Steps At this time, existing experimental implementations do not lead to a clear choice for what processing model enhancements should be in CDDL 2.0 follow-ons. This document proposes to continue the experimentation and document good approaches.

Module superstructure The previous content of this section formed the basis for . Additional work might be started on the ideas outlined in the subsections of this section.

Cross-universe references See .

ABNF is a lot like CDDL Many of the constructs defined here for CDDL also could be used with ABNF specifications. ABNF would definitely benefit from a standard way to import snippets from existing RFCs. Since CDDL contains ABNF support (), it would be natural to make some of the functionality discussed in this section available for ABNF as well.

IANA Considerations This document makes no requests of IANA.

Security considerations The security considerations of apply.

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. Informative References Universität Bremen TZI In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -19 // includes the definition of the cri'' application- extension. cri'' // was previously defined in draft-ietf-core-href; however the latter // document overtook the present document in the approval process. // As the definition of cri'' is dependent on the present document // (and conversely has essentially no dependency on the technical // content of draft-ietf-core-href beyond its mere existence), the // text (including IANA considerations) has been moved here. -19 is // intended for use at the CBOR WG meeting at IETF 124. Universität Bremen TZI The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. The Concise Data Definition Language (CDDL), as defined in RFCs 8610 and 9165, provides an easy and unambiguous way to express structures for protocol messages and data formats that are represented in Concise Binary Object Representation (CBOR) or JSON. This document updates RFC 8610 by addressing related errata reports and making other small fixes for the ABNF grammar defined for CDDL. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. Universität Bremen TZI Arm Limited At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. Universität Bremen TZI A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. n.d. Universität Bremen TZI CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. Universität Bremen TZI Fraunhofer SIT The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. Universität Bremen TZI TUD Dresden University of Technology The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -19 is a work-in-progress release in preparation for // another cbor-packed side meeting. This revision resolves the use // of the tunables A/B/C by setting A=16, B=8, and C=8, and choosing // requested simple values and tag numbers, in preparation for // continuing the early allocation process. Universität Bremen TZI CBOR (STD 94, RFC 8949) defines the concept of "Deterministically Encoded CBOR" in its Section 4.2, determining one specific way to encode each particular CBOR value. This definition is instantiated by "core requirements", providing some flexibility for application specific decisions; this makes it harder than necessary to offer Deterministic Encoding as a selectable feature of generic CBOR encoders. The present specification documents the Best Current Practice for CBOR _Common Deterministic Encoding_ (CDE), which can be shared by a large set of applications with potentially diverging detailed application requirements. The document also discusses the desire for partial implementations, which can be another reason for constraining CBOR encoders, and singles out the encoding constraint "definite-length-only" as a likely constraint to be used in application protocol and media type definitions. This specification updates RFC 8949 in that it provides clarifications and definitions of additional terms as well as more examples and explanatory text; it does not make technical changes to RFC 8949. // This revision -13 merges all active pull requests in preparation // for the 2025-cbor-17 interim on 2025-10-15. Universität Bremen TZI The Concise Binary Object Representation (CBOR, STD 94 == RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. Complex examples often use nested maps, the map keys (labels) for each of which are often sourced from different specifications. While the e'' application extension provides a way to import data items, particularly constant values, from a CDDL model, it does not help with automatically selecting the right kind of map depending on its position in the nested maps. // The present document is intended to capture ideas initially // discussed at the CBOR WG interim 2025-06-25 and demonstrate some // design alternatives. It is not ready for adoption yet in any way. n.d.

Fridge This appendix contains sections that may not make it to a 2.0 milestone, but might be part of a followup.

Tag-oriented Literals

Proposal Status:

rough idea, porting from EDN

Compatibility:

backward (not forward)

Some CBOR tags often would be most natural to use in a CDDL spec with a literal syntax that is tailored to their semantics instead of the serialization of their tag content in CBOR. There is currently no way to add such syntaxes, no defined extension point either. The specification "CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals, ABNF, and Media Type" defines application-oriented literals, e.g., of the form

• dt'2019-07-21T19:53Z'

for datetime items. With additional considerations for unambiguous syntax, a similar literal form could be included in CDDL. This proposal opens a namespace for the prefix that indicates an application specific literal. A registry could be provided to turn this namespace into a genuine extension point. (This is currently the production bsqual in .) The syntax provided in does not enable the use of named CDDL rules — using it directly in CDDL would have the same flaw that is being fixed for tag numbers in .

Cross-universe references Often, a CDDL specification needs to import from specifications in a different language or platform.

IANA references In many cases, CDDL specifications make use of values that are specified in IANA registries. The proposed .iana control operator can be used to reference such a set of values. The reference needs to be able to point to a draft, the registry of which has not been established yet, as well as to an established IANA registry. An example of such a usage might be: Unfortunately, the vocabulary employed in IANA registries has not been designed for machine references. In this case, the potential values would come from applying the XPath expression to https://www.iana.org/assignments/cose/cose.xml, plus some filtering on the records returned that only leaves actual allocations. contains an example of a CDDL module that is automatically generated from those assignments. (The code for this extraction is available in the document source repository of as .) Additional functionality may be needed for filtering with respect to other columns of the registry record, e.g., <capabilities> in the case of this example.

Acknowledgements TBD