<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-cbor-cddl-more-control-08" number="9741" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" updates="" obsoletes="" prepTime="2025-03-04T16:08:13" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-more-control-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9741" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="CDDL: More Control Operators for Text">Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text</title>
    <seriesInfo name="RFC" value="9741" stream="IETF"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>ART</area>
    <workgroup>cbor</workgroup>
    <keyword>Concise Data Definition Language</keyword>
    <keyword>Control Operator</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
      <t indent="0" pn="section-abstract-2">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9741" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-text-conversion">Text Conversion</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-byte-strings-base-16-hex-ba">Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-numerals">Numerals</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-printf-style-formatting">Printf-Style Formatting</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-json-values">JSON Values</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-text-processing">Text Processing</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-join">Join</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-list-of-figures">List of Figures</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-list-of-tables">List of Tables</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Concise Data Definition Language (CDDL), standardized in <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>,
provides "control operators" as its main language extension point
(<xref section="3.8" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#section-3.8" derivedContent="RFC8610"/>).
RFCs have added to this extension point in both an
application-specific <xref target="RFC9090" format="default" sectionFormat="of" derivedContent="RFC9090"/> and a more general <xref target="RFC9165" format="default" sectionFormat="of" derivedContent="RFC9165"/> way.</t>
      <t indent="0" pn="section-1-2">The present document defines a number of additional generally
applicable control operators. In <xref target="tbl-new" format="default" sectionFormat="of" derivedContent="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).</t>
      <table anchor="tbl-new" align="center" pn="table-1">
        <name slugifiedName="name-summary-of-new-control-oper">Summary of New Control Operators in This Document</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">t</th>
            <th align="left" colspan="1" rowspan="1">c</th>
            <th align="left" colspan="1" rowspan="1">Purpose</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64u</tt>, <tt>.b64c</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">bytes</td>
            <td align="left" colspan="1" rowspan="1">Base64 representation of byte strings</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64u-sloppy</tt>, <tt>.b64c-sloppy</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">bytes</td>
            <td align="left" colspan="1" rowspan="1">Sloppy-tolerant variants of the above</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.hex</tt>, <tt>.hexlc</tt>, <tt>.hexuc</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">bytes</td>
            <td align="left" colspan="1" rowspan="1">Base16 representation of byte strings</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b32</tt>, <tt>.h32</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">bytes</td>
            <td align="left" colspan="1" rowspan="1">Base32 representation of byte strings</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b45</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">bytes</td>
            <td align="left" colspan="1" rowspan="1">Base45 representation of byte strings</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.base10</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">int</td>
            <td align="left" colspan="1" rowspan="1">Text representation of integer numbers</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.printf</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">Printf-formatted text representation of data items</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.json</tt></td>
            <td align="left" colspan="1" rowspan="1">text</td>
            <td align="left" colspan="1" rowspan="1">any</td>
            <td align="left" colspan="1" rowspan="1">Text representation of JSON values</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.join</tt></td>
            <td align="left" colspan="1" rowspan="1">text or bytes</td>
            <td align="left" colspan="1" rowspan="1">array</td>
            <td align="left" colspan="1" rowspan="1">Build text or byte string from array of components</td>
          </tr>
        </tbody>
      </table>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
        <t indent="0" pn="section-1.1-2">Regular expressions mentioned in the text are as defined in <xref target="RFC9485" format="default" sectionFormat="of" derivedContent="RFC9485"/>.</t>
        <t indent="0" pn="section-1.1-3">This specification uses terminology from <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="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 <xref section="F" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-F" derivedContent="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".</t>
        <t indent="0" pn="section-1.1-4"> 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.
        </t>
      </section>
    </section>
    <section anchor="text-conversion" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-text-conversion">Text Conversion</name>
      <section anchor="base" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-byte-strings-base-16-hex-ba">Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64</name>
        <t indent="0" pn="section-2.1-1">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.</t>
        <t indent="0" pn="section-2.1-2">The control operators generally are of a form that could be used like
this:</t>
        <sourcecode type="cddl" name="example-b64u.cddl" markers="false" pn="section-2.1-3">
signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1
</sourcecode>
        <t indent="0" pn="section-2.1-4">The specification of these control operators cannot provide full
	coverage of the large number of transformations in use; it focuses on
	<xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/> and additionally <xref target="RFC9285" format="default" sectionFormat="of" derivedContent="RFC9285"/>, as shown in <xref target="tbl-text-conv" format="default" sectionFormat="of" derivedContent="Table 2"/>.
	For the representations defined in <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/>, this
	specification uses names as inspired by Section <xref target="RFC8949" section="8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-8" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>:
        </t>
        <table anchor="tbl-text-conv" align="center" pn="table-2">
          <name slugifiedName="name-control-operators-for-text-">Control Operators for Text Conversion of Byte Strings</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b64u</tt></td>
              <td align="left" colspan="1" rowspan="1">Base64url, no padding</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="5" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b64u-sloppy</tt></td>
              <td align="left" colspan="1" rowspan="1">Base64url, no padding, sloppy</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="5" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b64c</tt></td>
              <td align="left" colspan="1" rowspan="1">Base64 classic, padding</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="4" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b64c-sloppy</tt></td>
              <td align="left" colspan="1" rowspan="1">Base64 classic, padding, sloppy</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="4" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b32</tt></td>
              <td align="left" colspan="1" rowspan="1">Base32, no padding</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="6" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-6" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.h32</tt></td>
              <td align="left" colspan="1" rowspan="1">Base32 with "Extended Hex" alphabet, no padding</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="7" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-7" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.hex</tt></td>
              <td align="left" colspan="1" rowspan="1">Base16 (hex), either case</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="8" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.hexlc</tt></td>
              <td align="left" colspan="1" rowspan="1">Base16 (hex), lower case</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="8" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.hexuc</tt></td>
              <td align="left" colspan="1" rowspan="1">Base16 (hex), upper case</td>
              <td align="left" colspan="1" rowspan="1">
                <xref section="8" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent="RFC4648"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.b45</tt></td>
              <td align="left" colspan="1" rowspan="1">Base45</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC9285" format="default" sectionFormat="of" derivedContent="RFC9285"/></td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-2.1-6">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.</t>
        <t indent="0" pn="section-2.1-7">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 <tt>.b64u</tt> and <tt>.b64c</tt> 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.)</t>
        <t indent="0" pn="section-2.1-8">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 <xref section="4" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent="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 <xref target="RFC9285" format="default" sectionFormat="of" derivedContent="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).</t>
      </section>
      <section anchor="numerals" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-numerals">Numerals</name>
        <table anchor="tbl-num" align="center" pn="table-3">
          <name slugifiedName="name-control-operator-for-text-c">Control Operator for Text Conversion of Integers</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.base10</tt></td>
              <td align="left" colspan="1" rowspan="1">Base-ten (decimal) integer</td>
              <td align="left" colspan="1" rowspan="1">---</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-2.2-2">The control operator <tt>.base10</tt> allows the modeling of text strings
that carry an integer number in decimal form (as a text string with
digits in the usual base-ten positional numeral system), such as in the uint64/int64 formats of
YANG-JSON <xref target="RFC7951" format="default" sectionFormat="of" derivedContent="RFC7951"/>.</t>
        <sourcecode type="cddl" name="example-base10.cddl" markers="false" pn="section-2.2-3">
yang-json-sid = text .base10 (0..9223372036854775807)
</sourcecode>
        <t indent="0" pn="section-2.2-4">Again, the specification is opinionated by only providing for integer numbers
represented without leading zeros, i.e., the decimal integer
numerals match the regular
expression <tt>0|-?[1-9][0-9]*</tt> (of course, this is further restricted by the
control type).
See <xref target="printf-style-formatting" format="default" sectionFormat="of" derivedContent="Section 2.3"/> for more flexibility and for other numeric bases
such as octal, hexadecimal,
or binary conversions.</t>
        <t indent="0" pn="section-2.2-5">Note that this control operator governs text representations of
integers and should not be confused with the control operators
governing text representations of byte strings (such as <tt>.b64u</tt>).
This contrast is somewhat reinforced by spelling out "base" in the
name <tt>.base10</tt> as opposed to those of the byte string operators.</t>
      </section>
      <section anchor="printf-style-formatting" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-printf-style-formatting">Printf-Style Formatting</name>
        <table anchor="tbl-printf" align="center" pn="table-4">
          <name slugifiedName="name-control-operator-for-printf">Control Operator for Printf-Style Formatting of Data Item(s)</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.printf</tt></td>
              <td align="left" colspan="1" rowspan="1">Printf-style formatting of data item(s)</td>
              <td align="left" colspan="1" rowspan="1">---</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-2.3-2">The control operator <tt>.printf</tt> allows the modeling of text strings that carry various formatted
information, as long as the format can be represented in printf-style
formatting strings as they are used in the C language (see Section
7.23.6.1 of <xref target="C" format="default" sectionFormat="of" derivedContent="C"/>; note that the "C23" standard includes %b and %B for formatting into binary digits).</t>
        <t indent="0" pn="section-2.3-3">The controller (right-hand side) of the <tt>.printf</tt> control is an array
of one printf-style format string and zero or more data items that fit
the individual conversion specifications in the format string.


 The construct matches a text string representing the textual output of an
 equivalent C-language <tt>printf</tt> function call that receives as
 arguments the format string and the data items following it in the array.
        </t>
        <t indent="0" pn="section-2.3-4">Out of the functionality described for printf formatting in Section 7.23.6.1 of the C language specification <xref target="C" format="default" sectionFormat="of" derivedContent="C"/>, length modifiers (paragraph 7)
are not used and <bcp14>MUST NOT</bcp14> 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
<bcp14>MUST NOT</bcp14> be included in the format string.</t>
        <t indent="0" pn="section-2.3-5">In the following example, <tt>my_alg_19</tt> matches the text string <tt>"0x0013"</tt>:</t>
        <sourcecode type="cddl" name="example-printf.cddl" markers="false" pn="section-2.3-6">
my_alg_19 = hexlabel&lt;19&gt;
hexlabel&lt;K&gt; = text .printf (["0x%04x", K])
</sourcecode>
        <t indent="0" pn="section-2.3-7">The data items in the controller array do not need to be literals, as in the following 
example:</t>
        <sourcecode type="cddl" name="example-printf-uint.cddl" markers="false" pn="section-2.3-8">
any_alg = hexlabel&lt;1..20&gt;
hexlabel&lt;K&gt; = text .printf (["0x%04x", K])
</sourcecode>
        <t indent="0" pn="section-2.3-9">Here, <tt>any_alg</tt> matches the text strings <tt>"0x0013"</tt> or <tt>"0x0001"</tt> but
not <tt>"0x1234"</tt>.</t>
      </section>
      <section anchor="json-values" numbered="true" removeInRFC="false" toc="include" pn="section-2.4">
        <name slugifiedName="name-json-values">JSON Values</name>
        <t indent="0" pn="section-2.4-1">Some applications store complete JSON texts <xref target="STD90" format="default" sectionFormat="of" derivedContent="STD90"/> into text strings. The
JSON value of these can easily be defined in CDDL by using the default
JSON-to-CBOR conversion rules provided in Section <xref target="RFC8949" section="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>.
This is supported by a control operator similar to <tt>.cbor</tt> as defined in <xref section="3.8.4" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#section-3.8.4" derivedContent="RFC8610"/>.</t>
        <table anchor="tbl-json" align="center" pn="table-5">
          <name slugifiedName="name-control-operator-for-text-co">Control Operator for Text Conversion of JSON Values</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.json</tt></td>
              <td align="left" colspan="1" rowspan="1">JSON</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="STD90" format="default" sectionFormat="of" derivedContent="STD90"/></td>
            </tr>
          </tbody>
        </table>
        <sourcecode type="cddl" name="example-json.cddl" markers="false" pn="section-2.4-3">
embedded-claims = text .json claims
claims = {iss: text, exp: text}
</sourcecode>
        <t indent="0" pn="section-2.4-4">Notes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.4-5">
          <li pn="section-2.4-5.1">
            <t indent="0" pn="section-2.4-5.1.1">JSON has known interoperability problems <xref target="RFC7493" format="default" sectionFormat="of" derivedContent="RFC7493"/>.  While <xref section="4" sectionFormat="of" target="RFC7493" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7493#section-4" derivedContent="RFC7493"/> probably is not relevant to this specification,
            <xref section="2" sectionFormat="of" target="RFC7493" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7493#section-2" derivedContent="RFC7493"/> provides
            requirements that need to be followed to make use of the generic
            data model underlying CDDL.  Note that the intention of <xref section="2.2" sectionFormat="of" target="RFC7493" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7493#section-2.2" derivedContent="RFC7493"/> is directly
            supported by Section <xref target="RFC8949" section="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>.  The
            recommendation to use text strings for representing numbers
            outside JSON's interoperable range is a requirement on the
            application data model and therefore needs to be reflected on the
            right-hand side of the <tt>.json</tt> control operator.</t>
          </li>
          <li pn="section-2.4-5.2">
            <t indent="0" pn="section-2.4-5.2.1">This control operator provides no way to constrain the use of
            blank space or other serialization variants in the JSON
            representation of the data items; restrictions on the
            serialization to specific variants (e.g., not providing for the
            addition of any insignificant blank space and prescribing an order in
            which map entries are serialized) could be defined in future
            control operators.</t>
          </li>
          <li pn="section-2.4-5.3">
            <t indent="0" pn="section-2.4-5.3.1">A <tt>.jsonseq</tt> is not provided in this document for JSON text sequences <xref target="RFC7464" format="default" sectionFormat="of" derivedContent="RFC7464"/>, as no use case for inclusion in CDDL is known
            at the time of writing; again, future control operators could
            address this use case.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="text-processing" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-text-processing">Text Processing</name>
      <section anchor="join" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-join">Join</name>
        <t indent="0" pn="section-3.1-1">Often, text strings need to be constructed out of parts that can best
be modeled as an array.</t>
        <table anchor="tbl-join" align="center" pn="table-6">
          <name slugifiedName="name-control-operator-for-text-g">Control Operator for Text Generation from Arrays</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left" colspan="1" rowspan="1">Meaning</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">
                <tt>.join</tt></td>
              <td align="left" colspan="1" rowspan="1">Concatenate elements of an array</td>
              <td align="left" colspan="1" rowspan="1">---</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-3.1-3">For example, an IPv4 address in dotted-decimal might be modeled as in
<xref target="fig-join-example" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <figure anchor="fig-join-example" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-using-the-join-operator-to-">Using the .join Operator to Build Dotted-Decimal IPv4 Addresses</name>
          <sourcecode type="cddl" name="example-join.cddl" markers="false" pn="section-3.1-4.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
</sourcecode>
        </figure>
        <t indent="0" pn="section-3.1-5">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 of this concatenation is of the same kind of string (text
or bytes) as the first element of the array.
(If there is no element in the array, the <tt>.join</tt> construct matches
either kind of empty string, obviously further constrained by the
control operator target.)
The concatenation is performed on the sequences of bytes in the
strings.
If the result of the concatenation is a text string, the resulting
sequence of bytes only matches the target data item if that result is
a valid text string (i.e., valid UTF-8). Note that in contrast to the
algorithm used in Section <xref target="RFC8949" section="3.2.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.2.3" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>, there is no need
for all individual byte sequences going into the concatenation to
constitute valid text strings.</t>
        <t indent="0" pn="section-3.1-6">Note that this control operator is hard to validate in the most
general case, as this would require full parser functionality.
Simple implementation strategies will use array elements with constant
values as guideposts ("markers", such as the <tt>"."</tt> in <xref target="fig-join-example" format="default" sectionFormat="of" derivedContent="Figure 1"/>)
for isolating the variable elements that need further validation at
the CDDL data model level.
Therefore, it is recommended to limit the use of <tt>.join</tt> to simple
arrangements where the array elements are laid out explicitly and
there are no adjacent variable elements without intervening constant
values, and where these constant values do not occur within the text
described by the variable elements.
If more complex parsing functionality is required, the ABNF control
operators (see <xref section="3" sectionFormat="of" target="RFC9165" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9165#section-3" derivedContent="RFC9165"/>) may be useful; however, these
cannot reach back into CDDL-specified elements like <tt>.join</tt> can.</t>
        <aside pn="section-3.1-7">
          <t indent="0" pn="section-3.1-7.1">Implementation note: A validator implementation can use the marker
elements to scan the text and isolate the variable elements.
It also can 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 <xref section="6" sectionFormat="of" target="RFC9485" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9485#section-6" derivedContent="RFC9485"/>; see also
<xref section="8" sectionFormat="of" target="RFC9485" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9485#section-8" derivedContent="RFC9485"/> for security considerations related to
regexps.)
In the most general case, these implementation strategies can exhibit
false negatives, where the implementation cannot find the structure
that would be successfully validated using the controller; it is
<bcp14>RECOMMENDED</bcp14> that implementations provide full coverage at least for
the marker-based subset outlined in the previous paragraph.</t>
        </aside>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">IANA has registered the contents of <xref target="tbl-iana-reqs" format="default" sectionFormat="of" derivedContent="Table 7"/> into
      the "CDDL Control Operators" registry of <xref target="IANA.cddl" format="default" sectionFormat="of" derivedContent="IANA.cddl"/>:
      </t>
      <table anchor="tbl-iana-reqs" align="center" pn="table-7">
        <name slugifiedName="name-new-control-operators">New Control Operators</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64u</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64u-sloppy</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64c</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b64c-sloppy</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b45</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.b32</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.h32</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.hex</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.hexlc</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.hexuc</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.base10</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.printf</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.json</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">
              <tt>.join</tt></td>
            <td align="left" colspan="1" rowspan="1">RFC 9741</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">The security considerations in <xref section="5" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#section-5" derivedContent="RFC8610"/> apply. In addition, for the control operators defined
      in <xref target="base" format="default" sectionFormat="of" derivedContent="Section 2.1"/>, the security considerations in <xref section="12" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-12" derivedContent="RFC4648"/> apply.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="C" target="https://www.iso.org/standard/82075.html" quoteTitle="true" derivedAnchor="C">
          <front>
            <title>Information technology - Programming languages - C</title>
            <author>
              <organization showOnFrontPage="true">International Organization for Standardization</organization>
            </author>
            <date year="2024" month="October"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:2024"/>
          <annotation>Technically equivalent specification text is available at <eref target="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf" brackets="angle"/>.</annotation>
          <refcontent>Fourth Edition</refcontent>
        </reference>
        <reference anchor="IANA.cddl" target="https://www.iana.org/assignments/cddl" quoteTitle="true" derivedAnchor="IANA.cddl">
          <front>
            <title>Concise Data Definition Language (CDDL)</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC9165" target="https://www.rfc-editor.org/info/rfc9165" quoteTitle="true" derivedAnchor="RFC9165">
          <front>
            <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="December" year="2021"/>
            <abstract>
              <t indent="0">The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9165"/>
          <seriesInfo name="DOI" value="10.17487/RFC9165"/>
        </reference>
        <reference anchor="RFC9285" target="https://www.rfc-editor.org/info/rfc9285" quoteTitle="true" derivedAnchor="RFC9285">
          <front>
            <title>The Base45 Data Encoding</title>
            <author fullname="P. Fältström" initials="P." surname="Fältström"/>
            <author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/>
            <author fullname="D.W. van Gulik" initials="D.W." surname="van Gulik"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9285"/>
          <seriesInfo name="DOI" value="10.17487/RFC9285"/>
        </reference>
        <reference anchor="RFC9485" target="https://www.rfc-editor.org/info/rfc9485" quoteTitle="true" derivedAnchor="RFC9485">
          <front>
            <title>I-Regexp: An Interoperable Regular Expression Format</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="T. Bray" initials="T." surname="Bray"/>
            <date month="October" year="2023"/>
            <abstract>
              <t indent="0">This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9485"/>
          <seriesInfo name="DOI" value="10.17487/RFC9485"/>
        </reference>
        <referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/std90" derivedAnchor="STD90">
          <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true">
            <front>
              <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
              <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
              <date month="December" year="2017"/>
              <abstract>
                <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
                <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="90"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
          </reference>
        </referencegroup>
        <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94" derivedAnchor="STD94">
          <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true">
            <front>
              <title>Concise Binary Object Representation (CBOR)</title>
              <author fullname="C. Bormann" initials="C." surname="Bormann"/>
              <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
              <date month="December" year="2020"/>
              <abstract>
                <t indent="0">The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
                <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="94"/>
            <seriesInfo name="RFC" value="8949"/>
            <seriesInfo name="DOI" value="10.17487/RFC8949"/>
          </reference>
        </referencegroup>
      </references>
      <references anchor="sec-informative-references" pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC7464" target="https://www.rfc-editor.org/info/rfc7464" quoteTitle="true" derivedAnchor="RFC7464">
          <front>
            <title>JavaScript Object Notation (JSON) Text Sequences</title>
            <author fullname="N. Williams" initials="N." surname="Williams"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7464"/>
          <seriesInfo name="DOI" value="10.17487/RFC7464"/>
        </reference>
        <reference anchor="RFC7493" target="https://www.rfc-editor.org/info/rfc7493" quoteTitle="true" derivedAnchor="RFC7493">
          <front>
            <title>The I-JSON Message Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7493"/>
          <seriesInfo name="DOI" value="10.17487/RFC7493"/>
        </reference>
        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951" quoteTitle="true" derivedAnchor="RFC7951">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7951"/>
          <seriesInfo name="DOI" value="10.17487/RFC7951"/>
        </reference>
        <reference anchor="RFC9090" target="https://www.rfc-editor.org/info/rfc9090" quoteTitle="true" derivedAnchor="RFC9090">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags for Object Identifiers</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="July" year="2021"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR), defined in 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.</t>
              <t indent="0">This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9090"/>
          <seriesInfo name="DOI" value="10.17487/RFC9090"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="list-of-figures" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-list-of-figures">List of Figures</name>
      <t indent="0" pn="section-appendix.a-1"><xref target="fig-join-example" format="default" sectionFormat="of" derivedContent="Figure 1"/>: <xref target="fig-join-example" format="title" sectionFormat="of" derivedContent="Using the .join Operator to Build Dotted-Decimal IPv4 Addresses"/></t>
    </section>
    <section numbered="false" anchor="list-of-tables" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-list-of-tables">List of Tables</name>
      <t indent="0" pn="section-appendix.b-1"><xref target="tbl-new" format="default" sectionFormat="of" derivedContent="Table 1"/>: <xref target="tbl-new" format="title" sectionFormat="of" derivedContent="Summary of New Control Operators in This Document"/></t>
      <t indent="0" pn="section-appendix.b-2"><xref target="tbl-text-conv" format="default" sectionFormat="of" derivedContent="Table 2"/>: <xref target="tbl-text-conv" format="title" sectionFormat="of" derivedContent="Control Operators for Text Conversion of Byte Strings"/></t>
      <t indent="0" pn="section-appendix.b-3"><xref target="tbl-num" format="default" sectionFormat="of" derivedContent="Table 3"/>: <xref target="tbl-num" format="title" sectionFormat="of" derivedContent="Control Operator for Text Conversion of Integers"/></t>
      <t indent="0" pn="section-appendix.b-4"><xref target="tbl-printf" format="default" sectionFormat="of" derivedContent="Table 4"/>: <xref target="tbl-printf" format="title" sectionFormat="of" derivedContent="Control Operator for Printf-Style Formatting of Data Item(s)"/></t>
      <t indent="0" pn="section-appendix.b-5"><xref target="tbl-json" format="default" sectionFormat="of" derivedContent="Table 5"/>: <xref target="tbl-json" format="title" sectionFormat="of" derivedContent="Control Operator for Text Conversion of JSON Values"/></t>
      <t indent="0" pn="section-appendix.b-6"><xref target="tbl-join" format="default" sectionFormat="of" derivedContent="Table 6"/>: <xref target="tbl-join" format="title" sectionFormat="of" derivedContent="Control Operator for Text Generation from Arrays"/></t>
      <t indent="0" pn="section-appendix.b-7"><xref target="tbl-iana-reqs" format="default" sectionFormat="of" derivedContent="Table 7"/>: <xref target="tbl-iana-reqs" format="title" sectionFormat="of" derivedContent="New Control Operators"/></t>
    </section>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1"><contact fullname="Henk Birkholz"/> suggested the need for many of
      the control operators defined here.  The author would like to thank
      <contact fullname="Laurence Lundblade"/> and <contact fullname="Jeremy       O'Donoghue"/> for sharpening some of the mandates, <contact fullname="Mikolai Gütschow"/> for improvements to some examples,
      <contact fullname="A.J. Stein"/> for serving as shepherd for this
      document and for his shepherd review, the IESG and Directorate reviewers
      (notably <contact fullname="Ari Keränen"/>, <contact fullname="Darrel       Miller"/>, and <contact fullname="Éric Vyncke"/>), and <contact fullname="Orie Steele"/> for serving as responsible AD and for providing
      a detailed AD review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
