RFC 9741

Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text

📅 published March 2025, from ietf

RFC 9741: Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text 🎀

Okay bestie, here's the vibe check on this doc 💅

  • Stream: Internet Engineering Task Force (IETF)
  • Author: C. Bormann, Universität Bremen TZI
  • Category: Standards Track
  • Date: March 2025
  • ISSN: 2070-1721

Abstract ✨

So CDDL (standardized in RFC 8610) has this main extension point called "control operators," and RFCs have been adding stuff to it in both an application-specific way and a more general way 👀

This doc adds a bunch of extra generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for one operation on text 🌸

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9741.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🧚

1.  Introduction
  1.1.  Terminology
2.  Text Conversion
  2.1.  Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64
  2.2.  Numerals
  2.3.  Printf-Style Formatting
  2.4.  JSON Values
3.  Text Processing
  3.1.  Join
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
List of Figures
List of Tables
Acknowledgements
Author's Address

1. Introduction 💖

The Concise Data Definition Language (CDDL), standardized in [RFC8610], provides "control operators" as its main language extension point (Section 3.8 of [RFC8610]). RFCs have added to this extension point in both an application-specific [RFC9090] and a more general [RFC9165] way.

The present document defines a number of additional generally applicable control operators. In Table 1, the column marked t is for "target type" (left-hand side), and the column marked c is for "controller type" (right-hand side).

+===============+=========+=======+==============================+
| Name          | t       | c     | Purpose                      |
+===============+=========+=======+==============================+
| .b64u, .b64c  | text    | bytes | Base64 representation of     |
|               |         |       | byte strings                 |
+---------------+---------+-------+------------------------------+
| .b64u-sloppy, | text    | bytes | Sloppy-tolerant variants of  |
| .b64c-sloppy  |         |       | the above                    |
+---------------+---------+-------+------------------------------+
| .hex, .hexlc, | text    | bytes | Base16 representation of     |
| .hexuc        |         |       | byte strings                 |
+---------------+---------+-------+------------------------------+
| .b32, .h32    | text    | bytes | Base32 representation of     |
|               |         |       | byte strings                 |
+---------------+---------+-------+------------------------------+
| .b45          | text    | bytes | Base45 representation of     |
|               |         |       | byte strings                 |
+---------------+---------+-------+------------------------------+
| .base10       | text    | int   | Text representation of       |
|               |         |       | integer numbers              |
+---------------+---------+-------+------------------------------+
| .printf       | text    | array | Printf-formatted text        |
|               |         |       | representation of data items |
+---------------+---------+-------+------------------------------+
| .json         | text    | any   | Text representation of JSON  |
|               |         |       | values                       |
+---------------+---------+-------+------------------------------+
| .join         | text or | array | Build text or byte string    |
|               | bytes   |       | from array of components     |
+---------------+---------+-------+------------------------------+

    Table 1: Summary of New Control Operators in This Document

1.1. Terminology 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Regular expressions mentioned in the text are as defined in [RFC9485].

This specification uses terminology from [RFC8610]. In particular, with respect to control operators, "target" refers to the left-hand-side operand and "controller" to the right-hand-side operand. "Tool" refers to tools along the lines of that described in Appendix F of [RFC8610]. Note also that the data model underlying CDDL provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".

The term "opinionated" is used in this document to explain that the selection of operators included is somewhat frugal, based on opinions about what the preferred (and likely) usage scenarios will be. Specifically, not including a potential choice doesn't by itself intend to express that the choice is unacceptable; it might still be added in a future registration if these opinions evolve.

2. Text Conversion 🦋

2.1. Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64 🍓

A CDDL model often defines data that are byte strings in essence but need to be transported in various encoded forms, such as base64 or hex. This section defines a number of control operators to model these conversions.

The control operators generally are of a form that could be used like this:

signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1

The specification of these control operators cannot provide full coverage of the large number of transformations in use; it focuses on [RFC4648] and additionally [RFC9285], as shown in Table 2. For the representations defined in [RFC4648], this specification uses names as inspired by Section 8 of RFC 8949 [STD94]:

+==============+===========================+========================+
| Name         | Meaning                   | Reference              |
+==============+===========================+========================+
| .b64u        | Base64url, no padding     | Section 5 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .b64u-sloppy | Base64url, no padding,    | Section 5 of           |
|              | sloppy                    | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .b64c        | Base64 classic, padding   | Section 4 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .b64c-sloppy | Base64 classic, padding,  | Section 4 of           |
|              | sloppy                    | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .b32         | Base32, no padding        | Section 6 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .h32         | Base32 with "Extended     | Section 7 of           |
|              | Hex" alphabet, no padding | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .hex         | Base16 (hex), either case | Section 8 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .hexlc       | Base16 (hex), lower case  | Section 8 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .hexuc       | Base16 (hex), upper case  | Section 8 of           |
|              |                           | [RFC4648]              |
+--------------+---------------------------+------------------------+
| .b45         | Base45                    | [RFC9285]              |
+--------------+---------------------------+------------------------+

    Table 2: Control Operators for Text Conversion of Byte Strings

Note that this specification is somewhat opinionated here: It does not provide base64url or base32(hex) encoding with padding or base64 classic without padding. Experience indicates that these combinations only ever occur in error, so the usability of CDDL is increased by not providing them in the first place. Also, adding "c" makes sure that any decision for classic base64 is actively taken.

These control operators are "strict" in their matching, i.e., they only match base encodings that conform to the mandates of their defining documents. Note that this also means that .b64u and .b64c only match text strings composed of the set of characters defined for each of them, respectively. (This is perhaps worth pointing out explicitly as it contrasts with the "b64" literal prefix that can be used to notate byte strings in CDDL source code, which simply accepts characters from either alphabet. This behavior is different from the matching behavior of the four base64 control operators defined here.)

The additional designation "sloppy" indicates that the text string is not validated for any additional bits being zero, in variance to what is specified in the paragraph that follows Table 1 in Section 4 of [RFC4648]. Note that the present specification is opinionated again in not specifying a sloppy variant of base32 or base32hex, as no legacy use of sloppy base32(hex) was known at the time of writing. Base45 [RFC9285] is known to be suboptimal for use in environments with limited data transparency (such as URLs) but is included because of its close relationship to QR codes and its wide use in health informatics (note that base45 is strongly specified not to allow sloppy forms of encoding).

2.2. Numerals 🔢✨

okay so numerals time 💅 The .base10 control operator lets you say "this text string is secretly a decimal integer," which is exactly what the uint64/int64 stuff in YANG-JSON [RFC7951] needs 💖

           +=========+============================+===========+
           | Name    | Meaning                    | Reference |
           +=========+============================+===========+
           | .base10 | Base-ten (decimal) integer | ---       |
           +---------+----------------------------+-----------+

             Table 3: Control Operator for Text Conversion of
                                 Integers

so the operator covers text that holds an integer in decimal form (digits in the usual base-ten positional system), like this:

yang-json-sid = text .base10 (0..9223372036854775807)

the spec is lowkey opinionated here 🙈 It only allows integers without leading zeros. So decimal integers match the regex 0|-?[1-9][0-9]*, and of course the control type restricts it even further. If you want more flexibility, or other bases like octal, hexadecimal, or binary, check out Section 2.3 🧚

also, this control operator is for text representations of integers, so don't mix it up with the ones for byte strings (like .b64u) 👀 Spelling out "base" in .base10 makes that contrast extra clear.

2.3. Printf-Style Formatting 🖨️🌸

the .printf operator lets you model text strings with all kinds of formatted info, as long as the format fits printf-style formatting strings like the ones in C (see Section 7.23.6.1 of [C]; fun fact, the "C23" standard adds %b and %B for formatting binary digits 🤓).

     +=========+=========================================+===========+
     | Name    | Meaning                                 | Reference |
     +=========+=========================================+===========+
     | .printf | Printf-style formatting of data item(s) | ---       |
     +---------+-----------------------------------------+-----------+

       Table 4: Control Operator for Printf-Style Formatting of Data
                                  Item(s)

the right-hand side of the .printf control is an array. It holds one printf-style format string, plus zero or more data items that fit the conversion specifications in that format string. The construct matches a text string that equals the output of a C printf call, where the format string and the data items after it are the arguments 🎀

now the big-girl rules 💀 Out of everything in Section 7.23.6.1 of the C language specification [C], length modifiers (paragraph 7) are not used, and they MUST NOT be included in the format string. The "s" conversion specifier (paragraph 8) is used to interpolate a text string in UTF-8 form. The "c" conversion specifier (paragraph 8) represents a single Unicode scalar value as a UTF-8 character. The "p" and "n" conversion specifiers (paragraph 8) are not used, and they MUST NOT be included in the format string.

✨ Heads up: length modifiers, "p", and "n" are all a big no in the format string. MUST NOT means MUST NOT, bestie.

here's an example where my_alg_19 matches the text string "0x0013":

my_alg_19 = hexlabel<19>
hexlabel<K> = text .printf (["0x%04x", K])

the data items in the controller array don't have to be literals, like this:

any_alg = hexlabel<1..20>
hexlabel<K> = text .printf (["0x%04x", K])

in this one, any_alg matches "0x0013" or "0x0001", but NOT "0x1234" 🙅‍♀️

2.4. JSON Values 🧾💜

some apps store complete JSON texts [STD90] inside text strings. You can define the JSON value of those in CDDL by using the default JSON-to-CBOR conversion rules in Section 6.2 of RFC 8949 [STD94]. A control operator similar to .cbor (from Section 3.8.4 of [RFC8610]) supports this too 🫶

                      +=======+=========+===========+
                      | Name  | Meaning | Reference |
                      +=======+=========+===========+
                      | .json | JSON    | [STD90]   |
                      +-------+---------+-----------+

                         Table 5: Control Operator
                        for Text Conversion of JSON
                                   Values
embedded-claims = text .json claims
claims = {iss: text, exp: text}

Notes:

  • JSON has known interoperability problems [RFC7493]. Section 4 of [RFC7493] probably isn't relevant to this specification, but Section 2 of [RFC7493] has requirements you need to follow to use the generic data model underlying CDDL 🤓 Also, the intention of Section 2.2 of [RFC7493] is directly supported by Section 6.2 of RFC 8949 [STD94]. The recommendation to use text strings for numbers outside JSON's interoperable range is a requirement on the application data model, so it needs to be reflected on the right-hand side of the .json control operator.
  • This control operator gives you no way to constrain blank space or other serialization variants in the JSON representation of data items. Restrictions on serialization to specific variants (for example, not allowing any insignificant blank space, or setting an order for map entries) could be defined in future control operators 🍓
  • A .jsonseq isn't provided in this document for JSON text sequences [RFC7464], because no use case for it in CDDL is known at the time of writing. Again, future control operators could address this use case 🌈

3. Text Processing 🧁

3.1. Join 🧩

sometimes text strings need to be built out of parts that are best modeled as an array 🎀

         +=======+==================================+===========+
         | Name  | Meaning                          | Reference |
         +=======+==================================+===========+
         | .join | Concatenate elements of an array | ---       |
         +-------+----------------------------------+-----------+

            Table 6: Control Operator for Text Generation from
                                  Arrays

for example, an IPv4 address in dotted-decimal can be modeled like this (Figure 1) 🦋

legacy-ip-address = text .join legacy-ip-address-elements
legacy-ip-address-elements = [bytetext, ".", bytetext, ".",
                              bytetext, ".", bytetext]
bytetext = text .base10 byte
byte = 0..255
      Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4
                                 Addresses

the elements of the controller array need to be strings (text or byte strings). The control operator matches a data item if that data item is also a string, built by concatenating the strings in the array. The result is the same kind of string (text or bytes) as the first element of the array. (If the array is empty, .join matches either kind of empty string, further constrained by the control operator target, obvi 💅.) The concatenation happens on the sequences of bytes in the strings. If the result is a text string, the resulting bytes only match the target if they're a valid text string (valid UTF-8). Unlike the algorithm in Section 3.2.3 of RFC 8949 [STD94], there's no need for every individual byte sequence going into the concatenation to be a valid text string 🫧

this operator is hard to validate in the most general case, since that would take full parser functionality. Simple implementations use array elements with constant values as guideposts ("markers," like the "." in Figure 1) to isolate the variable elements that need more validation at the CDDL data model level. So it's RECOMMENDED to limit .join to simple arrangements where the array elements are laid out explicitly, there are no adjacent variable elements without constant values between them, and those constant values don't occur within the text described by the variable elements 🧠 If you need more complex parsing, the ABNF control operators (see Section 3 of [RFC9165]) might help, but they can't reach back into CDDL-specified elements the way .join can.

🛠️ Implementation note: A validator can use the marker elements to scan the text and isolate the variable elements. It can also build a parsing regexp from the elements of the controller array, with capture groups for each element, and validate the captures against the elements of the array. (For more about parsing regexps, see Section 6 of [RFC9485]; see also Section 8 of [RFC9485] for security considerations related to regexps.) In the most general case, these strategies can produce false negatives, where the implementation can't find the structure that would have validated successfully against the controller. It is RECOMMENDED that implementations provide full coverage at least for the marker-based subset outlined in the previous paragraph.

4. IANA Considerations 📋

IANA has registered the contents of Table 7 into the "CDDL Control Operators" registry of [IANA.cddl]:

                       +==============+===========+
                       | Name         | Reference |
                       +==============+===========+
                       | .b64u        | RFC 9741  |
                       +--------------+-----------+
                       | .b64u-sloppy | RFC 9741  |
                       +--------------+-----------+
                       | .b64c        | RFC 9741  |
                       +--------------+-----------+
                       | .b64c-sloppy | RFC 9741  |
                       +--------------+-----------+
                       | .b45         | RFC 9741  |
                       +--------------+-----------+
                       | .b32         | RFC 9741  |
                       +--------------+-----------+
                       | .h32         | RFC 9741  |
                       +--------------+-----------+
                       | .hex         | RFC 9741  |
                       +--------------+-----------+
                       | .hexlc       | RFC 9741  |
                       +--------------+-----------+
                       | .hexuc       | RFC 9741  |
                       +--------------+-----------+
                       | .base10      | RFC 9741  |
                       +--------------+-----------+
                       | .printf      | RFC 9741  |
                       +--------------+-----------+
                       | .json        | RFC 9741  |
                       +--------------+-----------+
                       | .join        | RFC 9741  |
                       +--------------+-----------+

                           Table 7: New Control
                                Operators

5. Security Considerations 🔐😱

the security considerations in Section 5 of [RFC8610] apply. In addition, for the control operators defined in Section 2.1, the security considerations in Section 12 of [RFC4648] apply 🛡️

6. References ✨

6.1. Normative References 💜

Okay bestie, these are the docs the spec needs you to have read first 📚✨ Think of them as the required reading list for the group project.

6.2. Informative References 🌸

These ones are extra-credit reading, the "oh you should totally check this out" kind 🧚

List of Figures 🎀

  • Figure 1: Using the .join Operator to Build Dotted-Decimal IPv4 Addresses

List of Tables 🦋

  • Table 1: Summary of New Control Operators in This Document
  • Table 2: Control Operators for Text Conversion of Byte Strings
  • Table 3: Control Operator for Text Conversion of Integers
  • Table 4: Control Operator for Printf-Style Formatting of Data Item(s)
  • Table 5: Control Operator for Text Conversion of JSON Values
  • Table 6: Control Operator for Text Generation from Arrays
  • Table 7: New Control Operators

Acknowledgements 🫶

Okay, big thank-you energy time! 🥹 Henk Birkholz is the reason so many of these control operators exist at all, because he suggested the need for them. The author is also super grateful to Laurence Lundblade and Jeremy O'Donoghue for sharpening some of the mandates 💅, and to Mikolai Gütschow for improving some of the examples 🍓. A.J. Stein gets a shoutout for serving as shepherd for this document and for the shepherd review 👑. The IESG and Directorate reviewers were absolutely essential too, especially Ari Keränen, Darrel Miller, and Éric Vyncke 🌈. Last but definitely not least, Orie Steele served as responsible AD and gave a detailed AD review, which is seriously iconic behaviour 😭✨.

Author's Address 💖

Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org

📦 where this page comes from