rfc9741.original.xml   rfc9741.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
<!ENTITY nbsp "&#160;"> cName="draft-ietf-cbor-cddl-more-control-08" number="9741" category="std" consen
<!ENTITY zwsp "&#8203;"> sus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true
<!ENTITY nbhy "&#8209;"> " xml:lang="en" updates="" obsoletes="" prepTime="2025-03-04T16:08:13" indexIncl
<!ENTITY wj "&#8288;"> ude="true" scripts="Common,Latin" tocDepth="3">
]> <link href="https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-more-control
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -08" rel="prev"/>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.22 (Ruby 3.3. <link href="https://dx.doi.org/10.17487/rfc9741" rel="alternate"/>
4) --> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-cbor-cddl-more-control-08" category="std" consensus="true" submissionType=
"IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.24.0 -->
<front> <front>
<title abbrev="CDDL: More Control Operators for Text ">Concise Data Definiti <title abbrev="CDDL: More Control Operators for Text">Concise Data Definitio
on Language (CDDL): Additional Control Operators for the Conversion and Processi n Language (CDDL): Additional Control Operators for the Conversion and Processin
ng of Text</title> g of Text</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-cddl-more-control-0 <seriesInfo name="RFC" value="9741" stream="IETF"/>
8"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization showOnFrontPage="true">Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2025" month="January" day="09"/> <date month="03" year="2025"/>
<area>ART</area>
<workgroup>cbor</workgroup>
<keyword>Concise Data Definition Language</keyword> <keyword>Concise Data Definition Language</keyword>
<keyword>Control Operator</keyword> <keyword>Control Operator</keyword>
<abstract> <abstract pn="section-abstract">
<?line 69?> <t indent="0" pn="section-abstract-1">The Concise Data Definition Language
(CDDL), standardized in RFC 8610,
<t>The Concise Data Definition Language (CDDL), standardized in RFC 8610,
provides "control operators" as its main language extension point. provides "control operators" as its main language extension point.
RFCs have added to this extension point both in an RFCs have added to this extension point in both an
application-specific and a more general way.</t> application-specific and a more general way.</t>
<t>The present document defines a number of additional generally <t indent="0" pn="section-abstract-2">The present document defines a numbe
applicable control operators for text conversion (Bytes, Integers, r of additional generally
JSON, Printf-style formatting) and for an operation on text.</t> applicable control operators for text conversion (bytes, integers,
<!-- printf-style formatting, and JSON) and for an operation on text.</t>
[^status]
[^status]: Revision –00 of this WG draft ...
-->
</abstract> </abstract>
<note removeInRFC="true"> <boilerplate>
<name>About This Document</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t> "exclude" pn="section-boilerplate.1">
The latest revision of this draft can be found at <eref target="https:// <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
cbor-wg.github.io/cddl-more-control/"/>. >
Status information for this document may be found at <eref target="https <t indent="0" pn="section-boilerplate.1-1">
://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-more-control/"/>. This is an Internet Standards Track document.
</t> </t>
<t> <t indent="0" pn="section-boilerplate.1-2">
Discussion of this document takes place on the This document is a product of the Internet Engineering Task Force
Concise Binary Object Representation (CBOR) Maintenance and Extensions W (IETF). It represents the consensus of the IETF community. It has
orking Group mailing list (<eref target="mailto:cbor@ietf.org"/>), received public review and has been approved for publication by
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro the Internet Engineering Steering Group (IESG). Further
wse/cbor/"/>. information on Internet Standards is available in Section 2 of
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cbor/"/ RFC 7841.
>. </t>
</t> <t indent="0" pn="section-boilerplate.1-3">
<t>Source for this draft and an issue tracker can be found at Information about the current status of this document, any
<eref target="https://github.com/cbor-wg/cddl-more-control"/>.</t> errata, and how to provide feedback on it may be obtained at
</note> <eref target="https://www.rfc-editor.org/info/rfc9741" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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="sectio
n-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-te
rminology">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" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-text-conversion">Text Conversion</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-by
te-strings-base-16-hex-ba">Byte Strings: Base 16 (Hex), Base 32, Base 45, and Ba
se 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 derived
Content="" format="title" sectionFormat="of" target="name-numerals">Numerals</xr
ef></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 derived
Content="" format="title" sectionFormat="of" target="name-printf-style-formattin
g">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 derived
Content="" format="title" sectionFormat="of" target="name-json-values">JSON Valu
es</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" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-text-processing">Text Processing</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="" forma
t="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="" forma
t="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="" forma
t="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<?line 86?> <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn
="section-1">
<section anchor="intro"> <name slugifiedName="name-introduction">Introduction</name>
<name>Introduction</name> <t indent="0" pn="section-1-1">The Concise Data Definition Language (CDDL)
<t>The Concise Data Definition Language (CDDL), standardized in <xref targ , standardized in <xref target="RFC8610" format="default" sectionFormat="of" der
et="RFC8610"/>, ivedContent="RFC8610"/>,
provides "control operators" as its main language extension point provides "control operators" as its main language extension point
(<xref section="3.8" sectionFormat="of" target="RFC8610"/>). (<xref section="3.8" sectionFormat="of" target="RFC8610" format="default" derive
RFCs have added to this extension point both in an dLink="https://rfc-editor.org/rfc/rfc8610#section-3.8" derivedContent="RFC8610"/
application-specific <xref target="RFC9090"/> and a more general <xref target="R >).
FC9165"/> way.</t> RFCs have added to this extension point in both an
<t>The present document defines a number of additional generally application-specific <xref target="RFC9090" format="default" sectionFormat="of"
applicable control operators:</t> derivedContent="RFC9090"/> and a more general <xref target="RFC9165" format="def
<table anchor="tbl-new"> ault" sectionFormat="of" derivedContent="RFC9165"/> way.</t>
<name>Summary of New Control Operators in this Document,
 t = target typ <t indent="0" pn="section-1-2">The present document defines a number of ad
e (left-hand side), c = controller type (right-hand side)</name> ditional generally
applicable control operators. In <xref target="tbl-new" format="default" section
Format="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 Co
ntrol Operators in This Document</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">t</th> <th align="left" colspan="1" rowspan="1">t</th>
<th align="left">c</th> <th align="left" colspan="1" rowspan="1">c</th>
<th align="left">Purpose</th> <th align="left" colspan="1" rowspan="1">Purpose</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u</tt>, <tt>.b64c</tt></td> <tt>.b64u</tt>, <tt>.b64c</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">bytes</td> <td align="left" colspan="1" rowspan="1">bytes</td>
<td align="left">Base64 representation of byte strings</td> <td align="left" colspan="1" rowspan="1">Base64 representation of by
te strings</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u-sloppy</tt>, <tt>.b64c-sloppy</tt></td> <tt>.b64u-sloppy</tt>, <tt>.b64c-sloppy</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">bytes</td> <td align="left" colspan="1" rowspan="1">bytes</td>
<td align="left">(sloppy-tolerant variants of the above)</td> <td align="left" colspan="1" rowspan="1">Sloppy-tolerant variants of
the above</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hex</tt>, <tt>.hexlc</tt>, <tt>.hexuc</tt></td> <tt>.hex</tt>, <tt>.hexlc</tt>, <tt>.hexuc</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">bytes</td> <td align="left" colspan="1" rowspan="1">bytes</td>
<td align="left">Base16 representation of byte strings</td> <td align="left" colspan="1" rowspan="1">Base16 representation of by
te strings</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b32</tt>, <tt>.h32</tt></td> <tt>.b32</tt>, <tt>.h32</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">bytes</td> <td align="left" colspan="1" rowspan="1">bytes</td>
<td align="left">Base32 representation of byte strings</td> <td align="left" colspan="1" rowspan="1">Base32 representation of by
te strings</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b45</tt></td> <tt>.b45</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">bytes</td> <td align="left" colspan="1" rowspan="1">bytes</td>
<td align="left">Base45 representation of byte strings</td> <td align="left" colspan="1" rowspan="1">Base45 representation of by
te strings</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.base10</tt></td> <tt>.base10</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">int</td> <td align="left" colspan="1" rowspan="1">int</td>
<td align="left">Text representation of integer numbers</td> <td align="left" colspan="1" rowspan="1">Text representation of inte
ger numbers</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.printf</tt></td> <tt>.printf</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">array</td> <td align="left" colspan="1" rowspan="1">array</td>
<td align="left">Printf-formatted text representation of data items< <td align="left" colspan="1" rowspan="1">Printf-formatted text repre
/td> sentation of data items</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.json</tt></td> <tt>.json</tt></td>
<td align="left">text</td> <td align="left" colspan="1" rowspan="1">text</td>
<td align="left">any</td> <td align="left" colspan="1" rowspan="1">any</td>
<td align="left">Text representation of JSON values</td> <td align="left" colspan="1" rowspan="1">Text representation of JSON
values</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.join</tt></td> <tt>.join</tt></td>
<td align="left">text or bytes</td> <td align="left" colspan="1" rowspan="1">text or bytes</td>
<td align="left">array</td> <td align="left" colspan="1" rowspan="1">array</td>
<td align="left">Build text or byte string from array of components< <td align="left" colspan="1" rowspan="1">Build text or byte string f
/td> rom array of components</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="terminology"> <section anchor="terminology" numbered="true" removeInRFC="false" toc="inc
<name>Terminology</name> lude" pn="section-1.1">
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <name slugifiedName="name-terminology">Terminology</name>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t indent="0" pn="section-1.1-1">
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i ",
nterpreted as "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in <xref target="BCP14"/> (<xref target="RFC2119"/>) (<xref target="RF "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
C8174"/>) when, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here.</t> be
<?line -18?> interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
<t>Regular expressions mentioned in the text are as defined in <xref target="RFC ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
9485"/>.</t> ear in all capitals, as
<t>This specification uses terminology from <xref target="RFC8610"/>. shown here.
</t>
<t indent="0" pn="section-1.1-2">Regular expressions mentioned in the te
xt 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 fro
m <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC
8610"/>.
In particular, with respect to control operators, "target" refers to In particular, with respect to control operators, "target" refers to
the left-hand side operand, and "controller" to the right-hand side operand. 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" se "Tool" refers to tools along the lines of that described in <xref section="F" se
ctionFormat="of" target="RFC8610"/>. ctionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-edit
or.org/rfc/rfc8610#appendix-F" derivedContent="RFC8610"/>.
Note also that the data model underlying CDDL provides for text Note also that the data model underlying CDDL provides for text
strings as well as byte strings as two separate types, which are strings as well as byte strings as two separate types, which are
then collectively referred to as "strings".</t> 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> </section>
<section anchor="text-conversion"> <section anchor="text-conversion" numbered="true" removeInRFC="false" toc="i
<name>Text Conversion</name> nclude" pn="section-2">
<section anchor="base"> <name slugifiedName="name-text-conversion">Text Conversion</name>
<name>Byte Strings: Base 16 (Hex), Base 32, Base 45, Base 64</name> <section anchor="base" numbered="true" removeInRFC="false" toc="include" p
<t>A CDDL model often defines data that are byte strings in essence but n="section-2.1">
<name slugifiedName="name-byte-strings-base-16-hex-ba">Byte Strings: Bas
e 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 ar
e byte strings in essence but
need to be transported in various encoded forms, such as base64 or need to be transported in various encoded forms, such as base64 or
hex. hex.
This section defines a number of control operators to model these This section defines a number of control operators to model these
conversions.</t> conversions.</t>
<t>The control operators generally are of a form that could be used like <t indent="0" pn="section-2.1-2">The control operators generally are of a form that could be used like
this:</t> this:</t>
<sourcecode type="cddl" name="example-b64u.cddl"><![CDATA[ <sourcecode type="cddl" name="example-b64u.cddl" markers="false" pn="sec tion-2.1-3">
signature-for-json = text .b64u signature signature-for-json = text .b64u signature
signature = bytes .cbor COSE_Sign1 signature = bytes .cbor COSE_Sign1
]]></sourcecode> </sourcecode>
<t>The specification of these control operators is complicated by the <t indent="0" pn="section-2.1-4">The specification of these control oper
large number of transformations in use. Inspired by Section <xref target="RFC89 ators cannot provide full
49" section="8" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>, this coverage of the large number of transformations in use; it focuses on
specification uses representations defined in <xref target="RFC4648"/> with the <xref target="RFC4648" format="default" sectionFormat="of" derivedContent
following ="RFC4648"/> and additionally <xref target="RFC9285" format="default" sectionFor
names:</t> mat="of" derivedContent="RFC9285"/>, as shown in <xref target="tbl-text-conv" fo
<table anchor="tbl-text-conv"> rmat="default" sectionFormat="of" derivedContent="Table 2"/>.
<name>Control Operators for Text Conversion of Byte Strings</name> 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" se
ction="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 Operato
rs for Text Conversion of Byte Strings</name>
<thead> <thead>
<tr> <tr>
<th align="left">name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">meaning</th> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left">reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u</tt></td> <tt>.b64u</tt></td>
<td align="left">Base64URL, no padding</td> <td align="left" colspan="1" rowspan="1">Base64url, no padding</td
<td align="left"> >
<xref section="5" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="5" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u-sloppy</tt></td> <tt>.b64u-sloppy</tt></td>
<td align="left">Base64URL, no padding, sloppy</td> <td align="left" colspan="1" rowspan="1">Base64url, no padding, sl
<td align="left"> oppy</td>
<xref section="5" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="5" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64c</tt></td> <tt>.b64c</tt></td>
<td align="left">Base64 classic, padding</td> <td align="left" colspan="1" rowspan="1">Base64 classic, padding</
<td align="left"> td>
<xref section="4" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="4" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64c-sloppy</tt></td> <tt>.b64c-sloppy</tt></td>
<td align="left">Base64 classic, padding, sloppy</td> <td align="left" colspan="1" rowspan="1">Base64 classic, padding,
<td align="left"> sloppy</td>
<xref section="4" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="4" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b32</tt></td> <tt>.b32</tt></td>
<td align="left">Base32, no padding</td> <td align="left" colspan="1" rowspan="1">Base32, no padding</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<xref section="6" sectionFormat="of" target="RFC4648"/></td> <xref section="6" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-6" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.h32</tt></td> <tt>.h32</tt></td>
<td align="left">Base32/hex alphabet, no padding</td> <td align="left" colspan="1" rowspan="1">Base32 with "Extended Hex
<td align="left"> " alphabet, no padding</td>
<xref section="7" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="7" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-7" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hex</tt></td> <tt>.hex</tt></td>
<td align="left">Base16 (hex), either case</td> <td align="left" colspan="1" rowspan="1">Base16 (hex), either case
<td align="left"> </td>
<xref section="8" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="8" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hexlc</tt></td> <tt>.hexlc</tt></td>
<td align="left">Base16 (hex), lower case</td> <td align="left" colspan="1" rowspan="1">Base16 (hex), lower case<
<td align="left"> /td>
<xref section="8" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="8" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hexuc</tt></td> <tt>.hexuc</tt></td>
<td align="left">Base16 (hex), upper case</td> <td align="left" colspan="1" rowspan="1">Base16 (hex), upper case<
<td align="left"> /td>
<xref section="8" sectionFormat="of" target="RFC4648"/></td> <td align="left" colspan="1" rowspan="1">
<xref section="8" sectionFormat="of" target="RFC4648" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-8" derivedContent
="RFC4648"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b45</tt></td> <tt>.b45</tt></td>
<td align="left">Base45</td> <td align="left" colspan="1" rowspan="1">Base45</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<xref target="RFC9285"/></td> <xref target="RFC9285" format="default" sectionFormat="of" deriv
edContent="RFC9285"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note that this specification is somewhat opinionated here: It does no <t indent="0" pn="section-2.1-6">Note that this specification is somewha
t t opinionated here: It does not
provide base64url, base32 or base32hex encoding with padding, or provide base64url or base32(hex) encoding with padding or
base64 classic without padding. Experience indicates that these base64 classic without padding. Experience indicates that these
combinations only ever occur in error, so the usability of CDDL is combinations only ever occur in error, so the usability of CDDL is
increased by not providing them in the first place. Also, adding "c" increased by not providing them in the first place. Also, adding "c"
makes sure that any decision for classic base64 is actively taken.</t> makes sure that any decision for classic base64 is actively taken.</t>
<t>These control operators are "strict" in their matching, i.e., they <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 only match base encodings that conform to the mandates of their
defining documents. defining documents.
Note that this also means that <tt>.b64u</tt> and <tt>.b64c</tt> only match text 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, strings composed of the set of characters defined for each of them,
respectively. respectively.
(This is maybe worth pointing out here explicitly as this contrasts (This is perhaps worth pointing out explicitly as it contrasts
with the "b64" literal prefix that can be used to notate byte strings with the "b64" literal prefix that can be used to notate byte strings
in CDDL source code, which simply accepts characters from either alphabet. in CDDL source code, which simply accepts characters from either alphabet.
This behavior is different from the matching behavior of the four This behavior is different from the matching behavior of the four
base64 control operators defined here.)</t> base64 control operators defined here.)</t>
<t>The additional designation "sloppy" indicates that the text string is <t indent="0" pn="section-2.1-8">The additional designation "sloppy" ind icates that the text string is
not validated for any additional bits being zero, in variance to what not validated for any additional bits being zero, in variance to what
is specified in the paragraph behind table 1 in <xref section="4" sectionFormat= "of" target="RFC4648"/>. is specified in the paragraph that follows Table 1 in <xref section="4" sectionF ormat="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 Note that the present specification is opinionated again in not
specifying a sloppy variant of base32 or base32/hex, as no legacy use specifying a sloppy variant of base32 or base32hex, as no legacy use
of sloppy base32(/hex) was known at the time of writing. of sloppy base32(hex) was known at the time of writing.
Base45 <xref target="RFC9285"/> is known to be suboptimal for use in environment Base45 <xref target="RFC9285" format="default" sectionFormat="of" derivedContent
s with limited ="RFC9285"/> is known to be suboptimal for use in environments with limited
data transparency (such as URLs), but is included because of its close data transparency (such as URLs) but is included because of its close
relationship to QR codes and its wide use in health informatics (note relationship to QR codes and its wide use in health informatics (note
that base45 is strongly specified not to allow sloppy forms that base45 is strongly specified not to allow sloppy forms
of encoding).</t> of encoding).</t>
</section> </section>
<section anchor="numerals"> <section anchor="numerals" numbered="true" removeInRFC="false" toc="includ
<name>Numerals</name> e" pn="section-2.2">
<table anchor="tbl-num"> <name slugifiedName="name-numerals">Numerals</name>
<name>Control Operator for Text Conversion of Integers</name> <table anchor="tbl-num" align="center" pn="table-3">
<name slugifiedName="name-control-operator-for-text-c">Control Operato
r for Text Conversion of Integers</name>
<thead> <thead>
<tr> <tr>
<th align="left">name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">meaning</th> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left">reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.base10</tt></td> <tt>.base10</tt></td>
<td align="left">Base-ten (decimal) Integer</td> <td align="left" colspan="1" rowspan="1">Base-ten (decimal) intege
<td align="left">---</td> r</td>
<td align="left" colspan="1" rowspan="1">---</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The control operator <tt>.base10</tt> allows the modeling of text str ings <t indent="0" pn="section-2.2-2">The control operator <tt>.base10</tt> a llows the modeling of text strings
that carry an integer number in decimal form (as a text string with 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/i nt64 formats of digits in the usual base-ten positional numeral system), such as in the uint64/i nt64 formats of
YANG-JSON <xref target="RFC7951"/>.</t> YANG-JSON <xref target="RFC7951" format="default" sectionFormat="of" derivedCont
<sourcecode type="cddl" name="example-base10.cddl"><![CDATA[ ent="RFC7951"/>.</t>
<sourcecode type="cddl" name="example-base10.cddl" markers="false" pn="s
ection-2.2-3">
yang-json-sid = text .base10 (0..9223372036854775807) yang-json-sid = text .base10 (0..9223372036854775807)
]]></sourcecode> </sourcecode>
<t>Again, the specification is opinionated by only providing for integer <t indent="0" pn="section-2.2-4">Again, the specification is opinionated
numbers by only providing for integer numbers
and these only represented without leading zeros, i.e., the decimal integer represented without leading zeros, i.e., the decimal integer
numerals match the regular numerals match the regular
expression <tt>0|-?[1-9][0-9]*</tt> (of course, further restricted by the expression <tt>0|-?[1-9][0-9]*</tt> (of course, this is further restricted by th e
control type). control type).
See the next section for more flexibility, and for other numeric bases See <xref target="printf-style-formatting" format="default" sectionFormat="of" d erivedContent="Section 2.3"/> for more flexibility and for other numeric bases
such as octal, hexadecimal, such as octal, hexadecimal,
or binary conversions.</t> or binary conversions.</t>
<t>Note that this control operator governs text representations of <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 integers and should not be confused with the control operators
governing text representations of byte strings (<tt>b64u</tt> etc.). governing text representations of byte strings (such as <tt>.b64u</tt>).
This contrast is somewhat reinforced by spelling out "base" in the 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> name <tt>.base10</tt> as opposed to those of the byte string operators.</t>
</section> </section>
<section anchor="printf-style-formatting"> <section anchor="printf-style-formatting" numbered="true" removeInRFC="fal
<name>Printf-style Formatting</name> se" toc="include" pn="section-2.3">
<table anchor="tbl-printf"> <name slugifiedName="name-printf-style-formatting">Printf-Style Formatti
<name>Control Operator for Printf-formatting of Data Item(s)</name> ng</name>
<table anchor="tbl-printf" align="center" pn="table-4">
<name slugifiedName="name-control-operator-for-printf">Control Operato
r for Printf-Style Formatting of Data Item(s)</name>
<thead> <thead>
<tr> <tr>
<th align="left">name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">meaning</th> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left">reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.printf</tt></td> <tt>.printf</tt></td>
<td align="left">Printf-formatting of data item(s)</td> <td align="left" colspan="1" rowspan="1">Printf-style formatting o
<td align="left">---</td> f data item(s)</td>
<td align="left" colspan="1" rowspan="1">---</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The control operator <tt>.printf</tt> allows the modeling of text str <t indent="0" pn="section-2.3-2">The control operator <tt>.printf</tt> a
ings that carry various formatted llows the modeling of text strings that carry various formatted
information, as long as the format can be represented in Printf-style information, as long as the format can be represented in printf-style
formatting strings as they are used in the C language (see Section formatting strings as they are used in the C language (see Section
7.21.6.1 of <xref target="C"/>).</t> 7.23.6.1 of <xref target="C" format="default" sectionFormat="of" derivedContent=
<t>The controller (right-hand side) of the <tt>.printf</tt> control is a "C"/>; note that the "C23" standard includes %b and %B for formatting into binar
n array y digits).</t>
of one Printf-style format string and zero or more data items that fit <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 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 is given the The construct matches a text string representing the textual output of an
format string and the data items following it in the array.</t> equivalent C-language <tt>printf</tt> function call that receives as
<t>From the printf specification in the C language, length modifiers (pa arguments the format string and the data items following it in the array.
ragraph 7) </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 targ
et="C" format="default" sectionFormat="of" derivedContent="C"/>, length modifier
s (paragraph 7)
are not used and <bcp14>MUST NOT</bcp14> be included in the format string. are not used and <bcp14>MUST NOT</bcp14> be included in the format string.
The 's' conversion specifier (paragraph 8) is used to The "s" conversion specifier (paragraph 8) is used to
interpolate a text string in UTF-8 form. interpolate a text string in UTF-8 form.
The 'c' conversion specifier (paragraph 8) represents a single Unicode The "c" conversion specifier (paragraph 8) represents a single Unicode
scalar value as a UTF-8 character. scalar value as a UTF-8 character.
The 'p' and 'n' conversion specifiers (paragraph 8) are not used and The "p" and "n" conversion specifiers (paragraph 8) are not used and
<bcp14>MUST NOT</bcp14> be included in the format string.</t> <bcp14>MUST NOT</bcp14> be included in the format string.</t>
<t>In the following example, <tt>my_alg_19</tt> matches the text string <t indent="0" pn="section-2.3-5">In the following example, <tt>my_alg_19
<tt>"0x0013"</tt>:</t> </tt> matches the text string <tt>"0x0013"</tt>:</t>
<sourcecode type="cddl" name="example-printf.cddl"><![CDATA[ <sourcecode type="cddl" name="example-printf.cddl" markers="false" pn="s
my_alg_19 = hexlabel<19> ection-2.3-6">
hexlabel<K> = text .printf (["0x%04x", K]) my_alg_19 = hexlabel&lt;19&gt;
]]></sourcecode> hexlabel&lt;K&gt; = text .printf (["0x%04x", K])
<t>The data items in the controller array do not need to be literals, </sourcecode>
as for example in:</t> <t indent="0" pn="section-2.3-7">The data items in the controller array
<sourcecode type="cddl" name="example-printf-uint.cddl"><![CDATA[ do not need to be literals, as in the following
any_alg = hexlabel<1..20> example:</t>
hexlabel<K> = text .printf (["0x%04x", K]) <sourcecode type="cddl" name="example-printf-uint.cddl" markers="false"
]]></sourcecode> pn="section-2.3-8">
<t>Here, <tt>any_alg</tt> matches the text strings <tt>"0x0013"</tt> or any_alg = hexlabel&lt;1..20&gt;
<tt>"0x0001"</tt> but 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> not <tt>"0x1234"</tt>.</t>
</section> </section>
<section anchor="json-values"> <section anchor="json-values" numbered="true" removeInRFC="false" toc="inc
<name>JSON Values</name> lude" pn="section-2.4">
<t>Some applications store complete JSON texts <xref target="STD90"/> in <name slugifiedName="name-json-values">JSON Values</name>
to text strings, the <t indent="0" pn="section-2.4-1">Some applications store complete JSON t
JSON value for which can easily be defined in CDDL by using the default exts <xref target="STD90" format="default" sectionFormat="of" derivedContent="ST
JSON-to-CBOR conversion rules provided by Section <xref target="RFC8949" section D90"/> into text strings. The
="6.2" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>. JSON value of these can easily be defined in CDDL by using the default
This is supported by a control operator similar to <tt>.cbor</tt> as defined in JSON-to-CBOR conversion rules provided in Section <xref target="RFC8949" section
<xref section="3.8.4" sectionFormat="of" target="RFC8610"/>.</t> ="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org
<table anchor="tbl-json"> /rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="S
<name>Control Operator for Text Conversion of JSON Values</name> TD94" 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" deriv
edLink="https://rfc-editor.org/rfc/rfc8610#section-3.8.4" derivedContent="RFC861
0"/>.</t>
<table anchor="tbl-json" align="center" pn="table-5">
<name slugifiedName="name-control-operator-for-text-co">Control Operat
or for Text Conversion of JSON Values</name>
<thead> <thead>
<tr> <tr>
<th align="left">name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">meaning</th> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left">reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.json</tt></td> <tt>.json</tt></td>
<td align="left">JSON</td> <td align="left" colspan="1" rowspan="1">JSON</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<xref target="STD90"/></td> <xref target="STD90" format="default" sectionFormat="of" derived
Content="STD90"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<sourcecode type="cddl" name="example-json.cddl"><![CDATA[ <sourcecode type="cddl" name="example-json.cddl" markers="false" pn="sec tion-2.4-3">
embedded-claims = text .json claims embedded-claims = text .json claims
claims = {iss: text, exp: text} claims = {iss: text, exp: text}
]]></sourcecode> </sourcecode>
<t>Notes:</t> <t indent="0" pn="section-2.4-4">Notes:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
<li> .4-5">
<t>JSON has known interoperability problems <xref target="RFC7493"/> <li pn="section-2.4-5.1">
. <t indent="0" pn="section-2.4-5.1.1">JSON has known interoperability
While <xref section="4" sectionFormat="of" target="RFC7493"/> probably is not re problems <xref target="RFC7493" format="default" sectionFormat="of" derivedCont
levant to this ent="RFC7493"/>. While <xref section="4" sectionFormat="of" target="RFC7493" fo
specification, <xref section="2" sectionFormat="of" target="RFC7493"/> provides rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc7493#section-4" derive
requirements that dContent="RFC7493"/> probably is not relevant to this specification,
need to be followed to make use of the generic data model underlying <xref section="2" sectionFormat="of" target="RFC7493" format="defaul
CDDL. t" derivedLink="https://rfc-editor.org/rfc/rfc7493#section-2" derivedContent="RF
Note that the intention of <xref section="2.2" sectionFormat="of" target="RFC749 C7493"/> provides
3"/> is directly requirements that need to be followed to make use of the generic
supported by Section <xref target="RFC8949" section="6.2" sectionFormat="bare"/> data model underlying CDDL. Note that the intention of <xref sectio
of RFC 8949 <xref target="STD94"/>. n="2.2" sectionFormat="of" target="RFC7493" format="default" derivedLink="https:
The recommendation to use text strings for representing numbers //rfc-editor.org/rfc/rfc7493#section-2.2" derivedContent="RFC7493"/> is directly
outside JSON's interoperable range is a requirement on the supported by Section <xref target="RFC8949" section="6.2" sectionFor
application data model and therefore needs to be reflected on the mat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#sect
right-hand side of the <tt>.json</tt> control operator.</t> ion-6.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="def
ault" 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>
<li> <li pn="section-2.4-5.2">
<t>This control operator provides no way to constrain the use of bla <t indent="0" pn="section-2.4-5.2.1">This control operator provides
nk no way to constrain the use of
space or other serialization variants in the JSON representation of blank space or other serialization variants in the JSON
the data items; restrictions on the serialization to specific representation of the data items; restrictions on the
variants (e.g, not providing for the addition of any insignificant serialization to specific variants (e.g., not providing for the
blank space, prescribing an order in which map entries are addition of any insignificant blank space and prescribing an order i
serialized) could be defined in future control operators.</t> n
which map entries are serialized) could be defined in future
control operators.</t>
</li> </li>
<li> <li pn="section-2.4-5.3">
<t>A <tt>.jsonseq</tt> is not provided in this document for <xref ta <t indent="0" pn="section-2.4-5.3.1">A <tt>.jsonseq</tt> is not prov
rget="RFC7464"/>, as no ided in this document for JSON text sequences <xref target="RFC7464" format="def
use case for inclusion in CDDL is known at the time of writing; ault" sectionFormat="of" derivedContent="RFC7464"/>, as no use case for inclusio
again, future control operators could address this use case.</t> n in CDDL is known
at the time of writing; again, future control operators could
address this use case.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="text-processing"> <section anchor="text-processing" numbered="true" removeInRFC="false" toc="i
<name>Text Processing</name> nclude" pn="section-3">
<section anchor="join"> <name slugifiedName="name-text-processing">Text Processing</name>
<name>Join</name> <section anchor="join" numbered="true" removeInRFC="false" toc="include" p
<t>Often, text strings need to be constructed out of parts that can best n="section-3.1">
<name slugifiedName="name-join">Join</name>
<t indent="0" pn="section-3.1-1">Often, text strings need to be construc
ted out of parts that can best
be modeled as an array.</t> be modeled as an array.</t>
<table anchor="tbl-join"> <table anchor="tbl-join" align="center" pn="table-6">
<name>Control Operator for Text Generation from Arrays</name> <name slugifiedName="name-control-operator-for-text-g">Control Operato
r for Text Generation from Arrays</name>
<thead> <thead>
<tr> <tr>
<th align="left">name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">meaning</th> <th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left">reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.join</tt></td> <tt>.join</tt></td>
<td align="left">concatenate elements of an array</td> <td align="left" colspan="1" rowspan="1">Concatenate elements of a
<td align="left">---</td> n array</td>
<td align="left" colspan="1" rowspan="1">---</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>For example, an IPv4 address in dotted-decimal might be modeled as in <t indent="0" pn="section-3.1-3">For example, an IPv4 address in dotted-
<xref target="fig-join-example"/>.</t> decimal might be modeled as in
<figure anchor="fig-join-example"> <xref target="fig-join-example" format="default" sectionFormat="of" derivedConte
<name>Using the .join operator to build dotted-decimal IPv4 addresses< nt="Figure 1"/>.</t>
/name> <figure anchor="fig-join-example" align="left" suppress-title="false" pn
<sourcecode type="cddl" name="example-join.cddl"><![CDATA[ ="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="s
ection-3.1-4.1">
legacy-ip-address = text .join legacy-ip-address-elements legacy-ip-address = text .join legacy-ip-address-elements
legacy-ip-address-elements = [bytetext, ".", bytetext, ".", legacy-ip-address-elements = [bytetext, ".", bytetext, ".",
bytetext, ".", bytetext] bytetext, ".", bytetext]
bytetext = text .base10 byte bytetext = text .base10 byte
byte = 0..255 byte = 0..255
]]></sourcecode> </sourcecode>
</figure> </figure>
<t>The elements of the controller array need to be strings (text or byte <t indent="0" pn="section-3.1-5">The elements of the controller array ne ed to be strings (text or byte
strings). strings).
The control operator matches a data item if that data item is also a The control operator matches a data item if that data item is also a
string, built by concatenating the strings in the array. string, built by concatenating the strings in the array.
The result of this concatenation is of the same kind of string (text The result of this concatenation is of the same kind of string (text
or bytes) as the first element of the array. or bytes) as the first element of the array.
(If there is no element in the array, the <tt>.join</tt> construct matches (If there is no element in the array, the <tt>.join</tt> construct matches
either kind of empty string, obviously further constrained by the either kind of empty string, obviously further constrained by the
control operator target.) control operator target.)
The concatenation is performed on the sequences of bytes in the The concatenation is performed on the sequences of bytes in the
strings. strings.
If the result of the concatenation is a text string, the resulting 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 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 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=" algorithm used in Section <xref target="RFC8949" section="3.2.3" sectionFormat="
bare"/> of RFC 8949 <xref target="STD94"/> there is no need bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3
that all individual byte sequences going into the concatenation .2.3" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="defaul
constitute valid text strings).</t> t" sectionFormat="of" derivedContent="STD94"/>, there is no need
<t>Note that this control operator is hard to validate in the most 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. general case, as this would require full parser functionality.
Simple implementation strategies will use array elements with constant Simple implementation strategies will use array elements with constant
values as guideposts ("markers", such as the <tt>"."</tt> in <xref target="fig-j oin-example"/>) values as guideposts ("markers", such as the <tt>"."</tt> in <xref target="fig-j oin-example" format="default" sectionFormat="of" derivedContent="Figure 1"/>)
for isolating the variable elements that need further validation at for isolating the variable elements that need further validation at
the CDDL data model level. the CDDL data model level.
It is therefore recommended to limit the use of <tt>.join</tt> to simple Therefore, it is recommended to limit the use of <tt>.join</tt> to simple
arrangements where the array elements are laid out explicitly and arrangements where the array elements are laid out explicitly and
there are no adjacent variable elements without intervening constant there are no adjacent variable elements without intervening constant
values, and where these constant values do not occur within the text values, and where these constant values do not occur within the text
described by the variable elements.<br/> described by the variable elements.
If more complex parsing functionality is required, the ABNF control If more complex parsing functionality is required, the ABNF control
operators (see <xref section="3" sectionFormat="of" target="RFC9165"/>) may be u operators (see <xref section="3" sectionFormat="of" target="RFC9165" format="def
seful; however, these ault" derivedLink="https://rfc-editor.org/rfc/rfc9165#section-3" derivedContent=
cannot reach back into CDDL-specified elements like <tt>.join</tt> can do.</t> "RFC9165"/>) may be useful; however, these
<aside> cannot reach back into CDDL-specified elements like <tt>.join</tt> can.</t>
<t>Implementation note: A validator implementation can use the marker <aside pn="section-3.1-7">
elements to scan the text, isolating the variable elements. <t indent="0" pn="section-3.1-7.1">Implementation note: A validator im
It also can build a parsing regexp (<xref section="6" sectionFormat="of" target= plementation can use the marker
"RFC9485"/>; see also elements to scan the text and isolate the variable elements.
<xref section="8" sectionFormat="of" target="RFC9485"/> for security considerati It also can build a parsing regexp from the elements of the controller array, wi
ons related to th capture
regexps) from the elements of the controller array, with capture
groups for each element, and validate the captures against the groups for each element, and validate the captures against the
elements of the array. elements of the array. (For more about parsing regexps, see <xref section="6" se
ctionFormat="of" target="RFC9485" format="default" derivedLink="https://rfc-edit
or.org/rfc/rfc9485#section-6" derivedContent="RFC9485"/>; see also
<xref section="8" sectionFormat="of" target="RFC9485" format="default" derivedLi
nk="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 In the most general case, these implementation strategies can exhibit
false negatives, where the implementation cannot find the structure false negatives, where the implementation cannot find the structure
that would be successfully validated using the controller; it is that would be successfully validated using the controller; it is
<bcp14>RECOMMENDED</bcp14> that implementations provide full coverage at least f or <bcp14>RECOMMENDED</bcp14> that implementations provide full coverage at least f or
the marker-based subset outlined in the previous paragraph.</t> the marker-based subset outlined in the previous paragraph.</t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<name>IANA Considerations</name> c="include" pn="section-4">
<t><cref anchor="to-be-removed">RFC Editor: please replace RFC-XXXX with t <name slugifiedName="name-iana-considerations">IANA Considerations</name>
he RFC <t indent="0" pn="section-4-1">IANA has registered the contents of <xref t
number of this RFC and remove this note.</cref></t> arget="tbl-iana-reqs" format="default" sectionFormat="of" derivedContent="Table
<t>This document requests IANA to register the contents of 7"/> into
<xref target="tbl-iana-reqs"/> into the registry the "CDDL Control Operators" registry of <xref target="IANA.cddl" format="
"<xref section="CDDL Control Operators" relative="#cddl-control-operators" secti default" sectionFormat="of" derivedContent="IANA.cddl"/>:
onFormat="bare" target="IANA.cddl"/>" of <xref target="IANA.cddl"/>:</t> </t>
<table anchor="tbl-iana-reqs"> <table anchor="tbl-iana-reqs" align="center" pn="table-7">
<name>New Control Operators To Be Registered</name> <name slugifiedName="name-new-control-operators">New Control Operators</
name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u</tt></td> <tt>.b64u</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64u-sloppy</tt></td> <tt>.b64u-sloppy</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64c</tt></td> <tt>.b64c</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b64c-sloppy</tt></td> <tt>.b64c-sloppy</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b45</tt></td> <tt>.b45</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.b32</tt></td> <tt>.b32</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.h32</tt></td> <tt>.h32</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hex</tt></td> <tt>.hex</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hexlc</tt></td> <tt>.hexlc</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.hexuc</tt></td> <tt>.hexuc</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.base10</tt></td> <tt>.base10</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.printf</tt></td> <tt>.printf</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.json</tt></td> <tt>.json</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>.join</tt></td> <tt>.join</tt></td>
<td align="left">[RFC-XXXX]</td> <td align="left" colspan="1" rowspan="1">RFC 9741</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section removeInRFC="true" anchor="implementation-status"> <section anchor="security-considerations" numbered="true" removeInRFC="false
<name>Implementation Status</name> " toc="include" pn="section-5">
<!-- RFC7942 --> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t>In the CDDL tool described in <xref section="F" sectionFormat="of" target="RF <t indent="0" pn="section-5-1">The security considerations in <xref sectio
C8610"/>, n="5" sectionFormat="of" target="RFC8610" format="default" derivedLink="https://
the control operators defined in the present revision of this rfc-editor.org/rfc/rfc8610#section-5" derivedContent="RFC8610"/> apply. In addit
specification are implemented as of version 0.10.4.</t> ion, for the control operators defined
</section> in <xref target="base" format="default" sectionFormat="of" derivedContent=
<section anchor="security-considerations"> "Section 2.1"/>, the security considerations in <xref section="12" sectionFormat
<name>Security considerations</name> ="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/
<t>The security considerations in <xref section="5" sectionFormat="of" tar rfc4648#section-12" derivedContent="RFC4648"/> apply.</t>
get="RFC8610"/> apply, as well as those
in <xref section="12" sectionFormat="of" target="RFC4648"/> for the control oper
ators defined in <xref target="base"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references" pn="section-6">
<name>References</name> <name slugifiedName="name-references">References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references" pn="section-6.1">
<name>Normative References</name> <name slugifiedName="name-normative-references">Normative References</na
<referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/s me>
td90"> <reference anchor="C" target="https://www.iso.org/standard/82075.html" q
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rf uoteTitle="true" derivedAnchor="C">
c8259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Form
at</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Br
ay"/>
<date month="December" year="2017"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-base
d, language-independent data interchange format. It was derived from the ECMAScr
ipt Programming Language Standard. JSON defines a small set of formatting rules
for the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specificatio
ns of JSON, repairs specification errors, and offers experience-based interopera
bility 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/s
td94">
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf
c8949">
<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>The Concise Binary Object Representation (CBOR) is a data for
mat whose design goals include the possibility of extremely small code size, fai
rly small message size, and extensibility without the need for version negotiati
on. These design goals make it different from earlier binary serializations such
as ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improve
ments, new details, and errata fixes while keeping full compatibility with the i
nterchange 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>
<reference anchor="RFC8610">
<front> <front>
<title>Concise Data Definition Language (CDDL): A Notational Convent <title>Information technology - Programming languages - C</title>
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu <author>
res</title> <organization showOnFrontPage="true">International Organization fo
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/> r Standardization</organization>
<author fullname="C. Vigano" initials="C." surname="Vigano"/> </author>
<author fullname="C. Bormann" initials="C." surname="Bormann"/> <date year="2024" month="October"/>
<date month="June" year="2019"/>
<abstract>
<t>This document proposes a notational convention to express Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal
is to provide an easy and unambiguous way to express structures for protocol me
ssages and data formats that use CBOR or JSON.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <seriesInfo name="ISO/IEC" value="9899:2024"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/> <annotation>Technically equivalent specification text is available at
<eref target="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf" bracke
ts="angle"/>.</annotation>
<refcontent>Fourth Edition</refcontent>
</reference> </reference>
<reference anchor="IANA.cddl" target="https://www.iana.org/assignments/c ddl"> <reference anchor="IANA.cddl" target="https://www.iana.org/assignments/c ddl" quoteTitle="true" derivedAnchor="IANA.cddl">
<front> <front>
<title>Concise Data Definition Language (CDDL)</title> <title>Concise Data Definition Language (CDDL)</title>
<author> <author>
<organization>IANA</organization> <organization showOnFrontPage="true">IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="RFC9165"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Additional Control Operators for the Concise Data Definition <title>Key words for use in RFCs to Indicate Requirement Levels</tit
Language (CDDL)</title> le>
<author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="December" year="2021"/> <date month="March" year="1997"/>
<abstract> <abstract>
<t>The Concise Data Definition Language (CDDL), standardized in RF <t indent="0">In many standards track documents several words are
C 8610, provides "control operators" as its main language extension point.</t> used to signify the requirements in the specification. These words are often cap
<t>The present document defines a number of control operators that italized. This document defines these words as they should be interpreted in IET
were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for t F documents. This document specifies an Internet Best Current Practices for the
he construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7 Internet Community, and requests discussion and suggestions for improvements.</t
405) in CDDL specifications; and.feature for indicating the use of a non-basic f >
eature in an instance.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9165"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="DOI" value="10.17487/RFC9165"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC4648"> <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4 648" quoteTitle="true" derivedAnchor="RFC4648">
<front> <front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/> <date month="October" year="2006"/>
<abstract> <abstract>
<t>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 da ta, use of padding in encoded data, use of non-alphabet characters in encoded da ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA CK]</t> <t indent="0">This document describes the commonly used base 64, b ase 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. [ST ANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4648"/> <seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference> </reference>
<reference anchor="RFC9285"> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</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/rfc8
610" quoteTitle="true" derivedAnchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 ex
press Concise Binary Object Representation (CBOR) data structures (RFC 7049). It
s 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/rfc9
165" 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), standar
dized in RFC 8610, provides "control operators" as its main language extension p
oint.</t>
<t indent="0">The present document defines a number of control ope
rators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, an
d.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 523
4 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/rfc9
285" quoteTitle="true" derivedAnchor="RFC9285">
<front> <front>
<title>The Base45 Data Encoding</title> <title>The Base45 Data Encoding</title>
<author fullname="P. Fältström" initials="P." surname="Fältström"/> <author fullname="P. Fältström" initials="P." surname="Fältström"/>
<author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/> <author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/>
<author fullname="D.W. van Gulik" initials="D.W." surname="van Gulik "/> <author fullname="D.W. van Gulik" initials="D.W." surname="van Gulik "/>
<date month="August" year="2022"/> <date month="August" year="2022"/>
<abstract> <abstract>
<t>This document describes the Base45 encoding scheme, which is bu ilt upon the Base64, Base32, and Base16 encoding schemes.</t> <t indent="0">This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9285"/> <seriesInfo name="RFC" value="9285"/>
<seriesInfo name="DOI" value="10.17487/RFC9285"/> <seriesInfo name="DOI" value="10.17487/RFC9285"/>
</reference> </reference>
<reference anchor="RFC9485"> <reference anchor="RFC9485" target="https://www.rfc-editor.org/info/rfc9 485" quoteTitle="true" derivedAnchor="RFC9485">
<front> <front>
<title>I-Regexp: An Interoperable Regular Expression Format</title> <title>I-Regexp: An Interoperable Regular Expression Format</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="T. Bray" initials="T." surname="Bray"/> <author fullname="T. Bray" initials="T." surname="Bray"/>
<date month="October" year="2023"/> <date month="October" year="2023"/>
<abstract> <abstract>
<t>This document specifies I-Regexp, a flavor of regular expressio n that is limited in scope with the goal of interoperation across many different regular expression libraries.</t> <t indent="0">This document specifies I-Regexp, a flavor of regula r expression that is limited in scope with the goal of interoperation across man y different regular expression libraries.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9485"/> <seriesInfo name="RFC" value="9485"/>
<seriesInfo name="DOI" value="10.17487/RFC9485"/> <seriesInfo name="DOI" value="10.17487/RFC9485"/>
</reference> </reference>
<reference anchor="C" target="https://www.iso.org/standard/74528.html"> <referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/s
<front> td90" derivedAnchor="STD90">
<title>Information technology — Programming languages — C</title> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rf
<author> c8259" quoteTitle="true">
<organization>International Organization for Standardization</orga
nization>
</author>
<date year="2018" month="June"/>
</front>
<seriesInfo name="ISO/IEC" value="9899:2018"/>
<annotation>
 <!-- work around broken annotation content model -->
Technically equivalent specification text is available at <eref target="https://
web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www
/abq/c17_updated_proposed_fdis.pdf">https://web.archive.org/web/20181230041359if
_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf</
eref></annotation>
<refcontent>Fourth Edition</refcontent>
</reference>
<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/b
cp14">
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rf
c2119">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</t <title>The JavaScript Object Notation (JSON) Data Interchange Form
itle> at</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author fullname="T. Bray" initials="T." role="editor" surname="Br
<date month="March" year="1997"/> ay"/>
<date month="December" year="2017"/>
<abstract> <abstract>
<t>In many standards track documents several words are used to s <t indent="0">JavaScript Object Notation (JSON) is a lightweight
ignify the requirements in the specification. These words are often capitalized. , text-based, language-independent data interchange format. It was derived from
This document defines these words as they should be interpreted in IETF documen the ECMAScript Programming Language Standard. JSON defines a small set of format
ts. This document specifies an Internet Best Current Practices for the Internet ting rules for the portable representation of structured data.</t>
Community, and requests discussion and suggestions for improvements.</t> <t indent="0">This document removes inconsistencies with other s
pecifications of JSON, repairs specification errors, and offers experience-based
interoperability guidance.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference> </reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rf </referencegroup>
c8174"> <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/s
td94" derivedAnchor="STD94">
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf
c8949" quoteTitle="true">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ <title>Concise Binary Object Representation (CBOR)</title>
title> <author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="May" year="2017"/> <date month="December" year="2020"/>
<abstract> <abstract>
<t>RFC 2119 specifies common key words that may be used in proto <t indent="0">The Concise Binary Object Representation (CBOR) is
col specifications. This document aims to reduce the ambiguity by clarifying tha a data format whose design goals include the possibility of extremely small cod
t only UPPERCASE usage of the key words have the defined special meanings.</t> e size, fairly small message size, and extensibility without the need for versio
n negotiation. These design goals make it different from earlier binary serializ
ations such as ASN.1 and MessagePack.</t>
<t indent="0">This document obsoletes RFC 7049, providing editor
ial 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 th
e format.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference> </reference>
</referencegroup> </referencegroup>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references" pn="section-6.2">
<name>Informative References</name> <name slugifiedName="name-informative-references">Informative References
<reference anchor="RFC7464"> </name>
<reference anchor="RFC7464" target="https://www.rfc-editor.org/info/rfc7
464" quoteTitle="true" derivedAnchor="RFC7464">
<front> <front>
<title>JavaScript Object Notation (JSON) Text Sequences</title> <title>JavaScript Object Notation (JSON) Text Sequences</title>
<author fullname="N. Williams" initials="N." surname="Williams"/> <author fullname="N. Williams" initials="N." surname="Williams"/>
<date month="February" year="2015"/> <date month="February" year="2015"/>
<abstract> <abstract>
<t>This document describes the JavaScript Object Notation (JSON) t ext sequence format and associated media type "application/json-seq". A JSON tex t sequence consists of any number of JSON texts, all encoded in UTF-8, each pref ixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Fee d character (0x0A).</t> <t indent="0">This document describes the JavaScript Object Notati on (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 ASC II Line Feed character (0x0A).</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7464"/> <seriesInfo name="RFC" value="7464"/>
<seriesInfo name="DOI" value="10.17487/RFC7464"/> <seriesInfo name="DOI" value="10.17487/RFC7464"/>
</reference> </reference>
<reference anchor="RFC7493"> <reference anchor="RFC7493" target="https://www.rfc-editor.org/info/rfc7 493" quoteTitle="true" derivedAnchor="RFC7493">
<front> <front>
<title>The I-JSON Message Format</title> <title>The I-JSON Message Format</title>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray "/> <author fullname="T. Bray" initials="T." role="editor" surname="Bray "/>
<date month="March" year="2015"/> <date month="March" year="2015"/>
<abstract> <abstract>
<t>I-JSON (short for "Internet JSON") is a restricted profile of J SON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t> <t indent="0">I-JSON (short for "Internet JSON") is a restricted p rofile of JSON designed to maximize interoperability and increase confidence tha t software can process it successfully with predictable results.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7493"/> <seriesInfo name="RFC" value="7493"/>
<seriesInfo name="DOI" value="10.17487/RFC7493"/> <seriesInfo name="DOI" value="10.17487/RFC7493"/>
</reference> </reference>
<reference anchor="RFC9090"> <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7
<front> 951" quoteTitle="true" derivedAnchor="RFC7951">
<title>Concise Binary Object Representation (CBOR) Tags for Object I
dentifiers</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="July" year="2021"/>
<abstract>
<t>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 f
or version negotiation.</t>
<t>This document defines CBOR tags for object identifiers (OIDs) a
nd is the reference document for the IANA registration of the CBOR tags so defin
ed.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9090"/>
<seriesInfo name="DOI" value="10.17487/RFC9090"/>
</reference>
<reference anchor="RFC7951">
<front> <front>
<title>JSON Encoding of Data Modeled with YANG</title> <title>JSON Encoding of Data Modeled with YANG</title>
<author fullname="L. Lhotka" initials="L." surname="Lhotka"/> <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
<date month="August" year="2016"/> <date month="August" year="2016"/>
<abstract> <abstract>
<t>This document defines encoding rules for representing configura tion data, state data, parameters of Remote Procedure Call (RPC) operations or a ctions, and notifications defined using YANG as JavaScript Object Notation (JSON ) text.</t> <t indent="0">This document defines encoding rules for representin g configuration data, state data, parameters of Remote Procedure Call (RPC) oper ations or actions, and notifications defined using YANG as JavaScript Object Not ation (JSON) text.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7951"/> <seriesInfo name="RFC" value="7951"/>
<seriesInfo name="DOI" value="10.17487/RFC7951"/> <seriesInfo name="DOI" value="10.17487/RFC7951"/>
</reference> </reference>
<reference anchor="RFC9090" target="https://www.rfc-editor.org/info/rfc9
090" quoteTitle="true" derivedAnchor="RFC9090">
<front>
<title>Concise Binary Object Representation (CBOR) Tags for Object I
dentifiers</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="July" year="2021"/>
<abstract>
<t indent="0">The Concise Binary Object Representation (CBOR), def
ined 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 identifie
rs (OIDs) and is the reference document for the IANA registration of the CBOR ta
gs so defined.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9090"/>
<seriesInfo name="DOI" value="10.17487/RFC9090"/>
</reference>
</references> </references>
</references> </references>
<?line 462?> <section numbered="false" anchor="list-of-figures" removeInRFC="false" toc="
include" pn="section-appendix.a">
<section numbered="false" anchor="list-of-figures"> <name slugifiedName="name-list-of-figures">List of Figures</name>
<name>List of Figures</name> <t indent="0" pn="section-appendix.a-1"><xref target="fig-join-example" fo
<ol spacing="normal" type="1"><li> rmat="default" sectionFormat="of" derivedContent="Figure 1"/>: <xref target="fig
<t><xref target="fig-join-example">Using the .join operator to build d -join-example" format="title" sectionFormat="of" derivedContent="Using the .join
otted-decimal IPv4 addresses</xref></t> Operator to Build Dotted-Decimal IPv4 Addresses"/></t>
</li>
</ol>
</section> </section>
<section numbered="false" anchor="list-of-tables"> <section numbered="false" anchor="list-of-tables" removeInRFC="false" toc="i
<name>List of Tables</name> nclude" pn="section-appendix.b">
<ol spacing="normal" type="1"><li> <name slugifiedName="name-list-of-tables">List of Tables</name>
<t><xref target="tbl-new">Summary of New Control Operators in this Doc <t indent="0" pn="section-appendix.b-1"><xref target="tbl-new" format="def
ument</xref></t> ault" sectionFormat="of" derivedContent="Table 1"/>: <xref target="tbl-new" form
</li> at="title" sectionFormat="of" derivedContent="Summary of New Control Operators i
<li> n This Document"/></t>
<t><xref target="tbl-text-conv">Control Operators for Text Conversion <t indent="0" pn="section-appendix.b-2"><xref target="tbl-text-conv" forma
of Byte Strings</xref></t> t="default" sectionFormat="of" derivedContent="Table 2"/>: <xref target="tbl-tex
</li> t-conv" format="title" sectionFormat="of" derivedContent="Control Operators for
<li> Text Conversion of Byte Strings"/></t>
<t><xref target="tbl-num">Control Operator for Text Conversion of Inte <t indent="0" pn="section-appendix.b-3"><xref target="tbl-num" format="def
gers</xref></t> ault" sectionFormat="of" derivedContent="Table 3"/>: <xref target="tbl-num" form
</li> at="title" sectionFormat="of" derivedContent="Control Operator for Text Conversi
<li> on of Integers"/></t>
<t><xref target="tbl-printf">Control Operator for Printf-formatting of <t indent="0" pn="section-appendix.b-4"><xref target="tbl-printf" format="
Data Item(s)</xref></t> default" sectionFormat="of" derivedContent="Table 4"/>: <xref target="tbl-printf
</li> " format="title" sectionFormat="of" derivedContent="Control Operator for Printf-
<li> Style Formatting of Data Item(s)"/></t>
<t><xref target="tbl-json">Control Operator for Text Conversion of JSO <t indent="0" pn="section-appendix.b-5"><xref target="tbl-json" format="de
N Values</xref></t> fault" sectionFormat="of" derivedContent="Table 5"/>: <xref target="tbl-json" fo
</li> rmat="title" sectionFormat="of" derivedContent="Control Operator for Text Conver
<li> sion of JSON Values"/></t>
<t><xref target="tbl-join">Control Operator for Text Generation from A <t indent="0" pn="section-appendix.b-6"><xref target="tbl-join" format="de
rrays</xref></t> fault" sectionFormat="of" derivedContent="Table 6"/>: <xref target="tbl-join" fo
</li> rmat="title" sectionFormat="of" derivedContent="Control Operator for Text Genera
<li> tion from Arrays"/></t>
<t><xref target="tbl-iana-reqs">New Control Operators To Be Registered <t indent="0" pn="section-appendix.b-7"><xref target="tbl-iana-reqs" forma
</xref></t> t="default" sectionFormat="of" derivedContent="Table 7"/>: <xref target="tbl-ian
</li> a-reqs" format="title" sectionFormat="of" derivedContent="New Control Operators"
</ol> /></t>
</section> </section>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc=
<name>Acknowledgements</name> "include" pn="section-appendix.c">
<t><contact fullname="Henk Birkholz"/> suggested the need for many of the <name slugifiedName="name-acknowledgements">Acknowledgements</name>
control operators <t indent="0" pn="section-appendix.c-1"><contact fullname="Henk Birkholz"/
defined here. > suggested the need for many of
The author would like to thank the control operators defined here. The author would like to thank
<contact fullname="Laurence Lundblade"/> and <contact fullname="Jeremy O'Donoghu <contact fullname="Laurence Lundblade"/> and <contact fullname="Jeremy
e"/> for sharpening some of O'Donoghue"/> for sharpening some of the mandates, <contact fullname="Mikolai
the mandates, Gütschow"/> for improvements to some examples,
<contact fullname="Mikolai Gütschow"/> for improvements to some examples, <contact fullname="A.J. Stein"/> for serving as shepherd for this
<contact fullname="A.J. Stein"/> for serving as shepherd for this document and f document and for his shepherd review, the IESG and Directorate reviewers
or his (notably <contact fullname="Ari Keränen"/>, <contact fullname="Darrel
shepherd review, Miller"/>, and <contact fullname="Éric Vyncke"/>), and <contact fullname="Orie
the IESG and Directorate reviewers (notably Steele"/> for serving as responsible AD and for providing
<contact fullname="Ari Keränen"/>, a detailed AD review.</t>
<contact fullname="Darrel Miller"/>, </section>
and <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<contact fullname="Éric Vyncke"/>), ="include" pn="section-appendix.d">
and <contact fullname="Orie Steele"/> for serving as responsible AD and for prov <name slugifiedName="name-authors-address">Author's Address</name>
iding a <author initials="C." surname="Bormann" fullname="Carsten Bormann">
detailed AD review.</t> <organization showOnFrontPage="true">Universität Bremen TZI</organizatio
n>
<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> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA7Vc3XYbx5G+76foQGfXRBYYAiBIkZAthxIlm44kOiKVbFbR
moNBAxhzMANPz5CEKebkdq93HyEX+xB75zfJk+xX1d3zgwFJ2Ul4dERguru6
u7p+vqquYbfbFZcjuSNEFmaRGsmnQsrnSRyEWskjP/PlkZqGcZiFSSxf+fEs
92dKbj0/OnrVHqHr4WTCbX5Eo7I0ieTJUqV+lqRaTpNUZnNFLZcq1UTCjyfy
2zQJlNZhPJPJVJ6p60z443GqLu3soD2Sr5NU3UGSR0ySIPYXWPAk9adZN1TZ
tBuMk7QbTCZRd4HR3cCM7kZ+pnQmHskJPozkoDfY7fb63d6BCPxsJHU2Eeiq
VaxzPZJZmiuhs1T5i5E8fnH2UogLtbpK0gn2232QN7ZPbdniUsW5InbN0iRf
jmTLUXkWxn66kifj71WQybdqmSqsI/OZ5NbzZydv2/K1H8aZiv04UMy+F9f4
RszULVBc+GEEgrT13xATvCSd0fNZmM3zsW3pXs22G3yhXoY16DXPsqUebW/b
3p4Z7oVJc9x2S4hlOJLvsyToSJ2k4NVU49NqYT4EyWLpBxl/WGA3+oMQfp7N
k5RY0JXm3J77qcZG5LMkXfhxjBYpsfaRfBeHLC3ZT3/N5LNUgYQ8+49j7kDn
orDebxOdTf1gLnd2esNhj9uCMFuN7ADzIJlgnqPuYH9n98A+ybEF9PpK0aQr
fricJzH6/dvwoDsc9LuD/n53b+dg0OdGZfgb+OPkN9mPIXFXCBHTmjMskzZ0
enZ00Btx7+5Ifq+TGKKGny9G8u3L5/sDnps6DYtOxOVap4MhdaJPe/0e2sFz
fD8+fHPo0eeRaTzo7+2i0RxD3zwb7g33R3Lsa2X7DPZ3zffhroTIJ1cxTuVX
tnFIjWGqZup6SapmVpT56Yy46oTg6urKC3VCm93WGWTOTyfbj4e7g31vni0i
M8aYi+N4angBec1UMI+TKJmt5N/+8j+k5rPUXyxIzyOrHZpbnjOFUiRIKPjo
jyHoaexbg3KSzvw4/NEQJ8U/tWuxz3ik02mcWm/PyIhKQwXrMk0MbfDx9GT7
+MXzkTzYPzgYUV9uAF+Il5BQt4iXSZ5mc/nC2DSzyjh2rR8tOSn/9dE1rMj+
E/n5r7pdCdtwIX1oNpRznCYXisxcnFgttlPIBaQxkt3u04LKGfErDPwoWkn1
Qx5e+hF11EsVhFM8t0y9zmSopX8JQfTHEWxAJj8vTkqNPT8N5hBFPi1836b9
9Qc7vd6wD7kPp99tU297rMlSxV1YPO79fRb0t3UwGGxfzfpDat/2xz9sB/3H
3+VLYuzku2WaLBOND9NJqL3lZPpUhO7IjfhDrB5DCI3ka/WDe3SwA0nrsjoI
0QWb/DG0F3ZBiDPjEz7Fx8CsFIeuJjKMibgkLekIrO0ynECmWlYlZOL8REv6
WoaZJvMYF9InlTOdcpnAqHoCxLSc+5fg6mQC+lkChwVur3WU4wRiEdK5Cn+5
jOzhdN1RsV32JVlJOVMxFhHJK3/lma1aow5dDPIFf6DtYt2+jPPFWKXkBv3S
kVoK0crNRafe2KLxriQdQelet56tYNA7rEgzPOuIb05P3nSgi9jFFAe/Ailz
fBn0ss0LJ0J+bCkTFSt2WD7Jt3j/nziDLCczXnwc4ZTVZciT/u0v/93r0R6Y
dX/4yrhk6XmeYHnn01+EsGNKiGPaxiQPeCL7c/MopKe34ovKz98pJjc3jARu
b/8BciK2bm5OlVnyjrdPW7XE2/84Ebq5+ZIsdO+gd3u7SZ5ubqwHQPM/W7ZG
QnyUb+Cm5d0/H2W29j2wv7/NU7IZ94xtEsN85954b5ifd8yH4Lw5Hwl75fuY
ZB2/n8HZ7Q1hzmvoCfumDgQZIOn6rvm6OkqWy1Uxrft+z3xbpks3SyLwCzy/
9NMQv7XRAQjCOLlU7eZ8c3XN8+B3FLhPud3p/fvr7/2S/e0MzCz43WT5vfPt
DH7JfMPd5jyfNh/Ayi+YjxjTu2PK5nykhfSb4ocNs4XGZlq9qU9o5luyFf3k
+fw09VekD8b4WrNLJmLzAiZk48JMLbSdj5znnQzdMF+8um9/5AkgqlGudJOY
mQ+G6qH54Cvcubn9PcvDaFJrtYcmp2mysN2wAIoLALVJUT6Km5F8lI2jbqyu
DJb8onWaLxYUDaHrGzxtBn+wnmxaj6yx6/ztL/8rMvmFBbAyWy3hECKFeHBO
FlTD6sM1BOhhTRwU1vZKw9m82q11C4OKqCA0CJZ8lvsxlhZBICG9CdzI63en
Z62O+S3fnPDnty9+9+747Ysj+nz69eGrV8UHYXucfn3y7tVR+akc+fzk9esX
b47MYDyVtUei9frwj2ihpbZOvj07Pnlz+KpVMKOw/D6cBZzPWLEkpzh+kjVf
C7i+IA3Hzi/+6tnzb/tDeJEtdimDfv8Ajsx+2+8/HtK3q7mKzZRJDHhqvsK2
sd9QfsqeLIoQGC3DzI8AOeBI9RzRhpyrVME7/fo9sQdA4fNxsOwPn9oHtOva
Q8e42kNmXPNJY7Dh5IZHG6YpWFp7vsbu+noP/1j77phfefj5lxHcrez2978E
0BFv1SyPwB2EVymlOICIJR0OPhj2k3tgTaHTAsuMu3aIxUZmt7fs3XG49Vgg
19C7rBRSo18F0vEAruTST7MwoEV05BWCeBgCIpKRaDT8PMTNqE6LgiEyelki
aIl1HTID4omVwVKXWgbtKLmmTW6AJ1pnSRJVqONfEgGdRAnMA8/EaIUdp0/o
pSaqh5C1eBJey5cVzOWJNwlMDIQuMYOIDNtOE2IhDFNptCL7Q9hQFvDPAWbh
XAr4f6UgxPhdczX4nl0lCCTBTERBbDHAq6t5GMzp4IhFFNiBBQGFQVAQ3mBq
4B+GtyypFh0kHXeZAquBXMa5hNkR2/KAEXtDCXe/9bW6hvHirzsD+2G4az8A
79w8Iv93W7VUjR8hDg0TDGuSKWVcHERknjEHSRhrHAD3Ib6KUk7jPBOxMjuD
bUEIF+tlkmbmjAj6JDnQbkzZFo4lFpQLyolTmvMQWGqSCiAdz8q0RdKbkGoz
ysGsZu3guVaijHW0RcDNIQXG5X0R/uVlma0GSQ5nhY1AmSaQvgs6zZAQ75//
/GeTeNHhLEaQkypy2RzBkouhU2TEKIv2sic6GK/oUWpHPj85ffHdKRr7RJV8
nU7yNFDEoy6lv75oqWt/sYxUlyhyjocdEPZTV3mDKPWmbYKV5FE5ksBWxivq
KSLS5wpH+byKHA2fLHbuSYSIehmmZmAZ3lBwI2xG6jecUEUEZRzNBltUBxnr
1ozF89ZYIdLRKRQmuYJ8CWKBCTLiepDxEdbSj0l174YhrGosmg0AwwFE2dME
Bu/evurIOIFlRBhUo/yxsvFdtjB2yc3w4C5qEHXu8EnUgsbaZBD5cBNBp7G6
KrXhZmqNtTWoFat7iFo1QHABwB1MW1vbXpPafBO1bRgA2Ozl3B+rrEa6Su3x
BmoImtaokXWcs3VUkC3IeeAX4ebHNWFuUouKY1inBumsE/sEavmd1HI4r59F
rRY+FWHRnT8fnY4NKSVQbSjANRktSttfOoh994VK9ZIGK6v6JLJM7HKtt23Y
AnqQLNQVNSfLMKZUA5kkQoIjeUzZCRiLOMlcKsb6hTyNOvwR0SZFDvyJ5IS9
CckG245CmOFGxjVB5/Ykz1wXmLUX10vK/5J5CAEdyDbqAiawA1mMw9jaK8a2
6pIsZRDkDGrhxZOUrjXYZOXaH4dRmHFQwo401CKMg1T52phO7MoijNAgmoWD
edMw1WiL/IDM7SHgSkdakW8FLbHwL7AyTc7D+GBEbxNwVbtst9uj3TLlgB3a
yDA2Nv5vo2sgv8cQJMhsoKDCVMIFBHNmZOgpz8J5ZgG38EQF67Vzl7HxnYYf
C0qyZQ6wgahgk097cnGI9taFhZEa2XVL09lpQovOLlaWUYNoHDMSq21qRSPM
I5ww9ymVTJjS+RximaIrIdNz0REW+TLLPLHF4COkVN8K7h+hHIkWpeb4IhJC
ROJKyB0eFdqyYhg4Zy8L/vo606JwZS2sugX0kHFqDk5wCpBqGObHBboA0/ga
oA6uID9GlAwm4GsqBy51CIeOmYNALREmV7bJUN+aO2dGLaAaq7l/GWL7FA2G
U/aOmRlgzswce9nP8nKK+QuFasiQ4yuHc22DTSqJRABqBj8krS3jZVobNM7g
JpsOgO6Qulz6Uci3CzbzvKrSHVM2dqyo+48qhcpYkMnXn2AoGRlRWqAyqiKs
Pkv95Zz2iYVASSi32TdgZJPzqwtqmUttGLeqTfNnlCnGPzJnpieHGr5ztTYZ
yPmrNdNGPpADZXi/SM38YEVyItDTjjXdtqgfQnB0vIgponasDBcMZ6/SkGTW
E9ZDVN1A6MYYtK7zcbLEODCWeI3Z2MbFl2GaxKytxsRG4QKyPBEmJGCI7xPG
WsktB+UBfDS8GsIBmgQ2MMoJ8I9V4BNZSqCRxEbQVmheZCzsPFzSSn73lqVc
s8qHPOlEudXMlR9xatyi1EDLLTCXcDk2bm8y6cQhoPEM2lEePUkTBVyEKx0P
OQIhnjpL1oahfAPTBE3VooiLqtDzXtRZBZz1tKNx0V0KqbbIcoPLbXfzgka6
9Vh3yMDld7niuzyxu8px8cG6plYWxHzQRukpZrIVFhUV1MIaqTRd0Z1PPedJ
p2E3YiKmLZ/Cs6oKk7SISTijQ7SKl+uc9NaxAuba6XJsuC71Smdq0S7DQjcS
0+8Nt/l/eytFnkX88fDNV11OV5pLkccHu33OiRQh2sqPZxyZdXU4KaMz5oPc
6nnewWCws/N40NvZ298dPn68u9973H44FuPxRTR2SKreMW7nPpMAFMDuq4QB
dJRr6WRBom9COe5chE4g4FBMpPyJM3y64qWLQ7E0hWWsdh6TMjAm8yTKzJM8
733sfvm+3z348L6H/359Lrc4xM5TDYczpaturA+9GSiUIaSTMEp7QHlOleIZ
YhYDa0dph3w9NY3UdWgwUqe4TUyYMq/SAhgt3NknQeYD9sHE+XZbHUEW0lTC
1OP7NSDREP1Zgs4EK5oZbxYkyy9jd/ScQ3+yGWNWoyk76cKnN1ygMOQZ122e
oJ402To3uEZlgde2vtlhhxpGThUbu8CwHLIVRQ6DtIhZDrNxnCzPC/UmsTNo
iOFYYswurb2adC/WDwbW7n1fFve+v8AM3mkN3aXI+j2HNT7FpcaWbt9hFA2F
e+3iRtJ8J3xsSN9jHd0CP8E6yop1dJmt4tqmLHxIYvbinMP0tcVS1OLQX1W5
cZTVUxCVPVTzjcDiDNtZJq19fF7eSG9paKEFMeKxN+h7e16flv/++Yd2PRNG
dxyN6w0nKCU7HKcIoMfmkoa8ZhKrTdUCTriIIJkn6fS/cmnFzJuGGWeQCQrC
GpJrqNQn1Oxo4QdqU3huL/iaB5kxcWrdDxUctlEXN9JkUKJlTugLBrdaVfO8
W/Dy3LFgmsfGmlENjlk+uDFDwGDUr7n1ItVsdlxktPDdbYY5iRN56fC3Fe81
F7J+wh1Y/3gGUwTZJHADo7VVQlo4LxIOsl0sILQWd5tibnwsHLubo5/pzzac
BMlKOc1+mxhgYxdhrpESqhFc4z5meXf2srvP81jywSeRL86NDpRKQCFh7+KQ
nLHQOAY/NVeUkpGHmaSIguxMy894/5/Fm2fUa1OuM078DMbRjUotdSktVujI
88XqOz+afdc/OC9kdD3gOW/1rnu9/k7rvJpfLgYCuFA+CqFc9Hn/4Kkovvz2
aYFprPRsvQepf+kNr1sd+dsPD0MZM6yWWK7Ird1sxWCYS9oJB6yyku63Ia7u
CN/kiuwEIFHdEoI42lNtQ5436P0T9tQl1Fhs7Gv4IpyFnf/Ok9CVoyDTZb71
+vjG9xvYND3qD3aGrXMcO4PP3/Ndef0m+BQ+XFbqdygsITPImXgFReGRNLOm
uIwgKkVlMTnsynIY1onyRp5Za1IA5EKUr0NgxLGqZtQ5ZzCmkNHZPDT6eZQx
nW6WdKleuKoSaR6BFTbntpbo3/MG5BPWUv0WtRBYyZf2lgfD/KZf1YgYSVux
sXO+9DhvXGc6d7Xj7XvD2gVeBXaUoKMJLUz9w0fDU5c/pWpbzneWAIKvaH5m
WFU5YZKjQpIV0DrVcXWDyA+hKk5meQ7zTBRNN6GminF06FDiyHy8fVCQiVYh
wYRx6S7k12ZJ8yLqZ/PL/LYpSBzkOCL1pZtiK1qekPIP8xAKuZ7jcD14mD+G
OIWcgwWXI3VJGQpbqQYKNd/UqZAaNEiZq9SUPCtXWmfG74NIxWoYc2m+Up5T
5iVU5ds5RAUbb2xt+T/tqp6b4RJ4dyNWWZ+3tkJOgaVojai4uybED8u+lGcc
SZm69YktwE149TVjQjJVQyAuyJOEP/gGnA7zM109RJxRCmevGHFVOcj1lnOq
364Ylip/LPKAepCpIT5ry2g8ojtoyo86Go2reAf8jDatKzJVasizjdFVcdpx
QhWHtoKAiniLyJ/Jj4FhLliKfKhuEf5RHbYfufrtokbOjmVhbxQpgUodYj0p
4lObsLdZ4CpprMsJMMYXE20pb9ZZy8+7N1JcwpFvh2OoRkzZTFaBmGSZt2Q2
1OG8IFUlGBCIDU5MqsTY64W/lNgB1ZxzbYAsVqcm7fK6uWIZpzlfGTfiTT6K
Q3tSWv1w7jS2sOCNmh/aj3UzGEBXtZxdxCLobPjuyeQigHK0xZ32GuPe3OIT
EkaT/rhrtXZr4CTlG8y63KTYiSl7KF/1aZY9fJOEsTBe9YTqEjp1HauYkyIY
IDlncM9lLkW4RjGXzsTYBnZc9VQENXd4m58R4ZqyuI+0DEpuU9JHYhZj/FiA
ilK4TeEtDX/YO33FRQsmt0KRwyFRZNf0skRdlGGRx99eDgu2U8Yuoei063JE
C9J/WecFGH1zMw1nvJauJVbPqJl8dDdcdh3pwvPR+hvNXceB5siiCSTeU2bC
OMiWB5xX/yruPgb6uWPsB+E+rWf+6Dk3oqEH/Lm763zxo/Xd3+Od0ct4Z1qe
Pbh3Begy/CiMJEko1z+uHUP1lFSRvK2KzUYEXpH6Iq1Urax0F2Ntb3O6o4yW
CxsqQ1dcVT6xl3K+JdfhPWTkJUshdxuu1ARV4lvjKTXgZ1H5Xxlqk6T2zo6U
74KuZOimw0RGvCnhiknbRRqF70wtl4pyajPj1vHUeEFjFote1XV1nK9jlW0k
EYS9QHOLUYslcJXjQTK+pIwPkJLLjRburpkcLQWAC+i8tjuPOgvQi0LKwkHD
OfyQk20p0oeOse5kPWH2WePuBsq1iLxTGUHG1s1STlJesLroyNTMNsXEzgtg
6JurulpIu2Wy0qaB4/Mn5KMsVAvjMuNprowFwrIETmW+KFJb1ZcpBt7OBihW
O2dSCXNtQVmaSl7JJD0Lfs4Sk5qwV9U1hvELnlDlHCMae9LtT0g1h/SSR8q6
6e4vneQtEjgf95oGub9OcXV8xT7SYj2IFTYAzwWAUOSefIL2njgNTVRN/y8K
QETCl6kZQYurEGPJvxo7URgSTl/z7gi52PJuTD/LgRiWWBkMSGvhpxd0hVTe
wLCawKqemwNp+oa2YOCgKf3jLAFDK8KxxezMMLZZTmUsc/hdX5MJZLxRQbOI
PlQEKedkWwlrC9htDCDfSFZRplNqQnvMJkGcAJ62fGCJKQxBuURK/yBeM8ih
ersfk1TRIJMggrH+HnDPvc5R26a7oGE0f6kYQKzx3Fx+FKvQqujgau5tcsVU
mhDFSjlwpUbb2JnmIrw//Yksw6LMNlyzLDGsrQoTsdVK3MTYhcNnb146iRYl
gOOcckUZTYhu3y6lIvCFv7K1DJDcJ3KOkA4RdMdV0vBLjpjK59qR4MLoHh13
t7yiLXhIpZalZfYJt0DtbkY+RSm34qk4rss+GZUR4LAVKBLGegeiwZEZ1ziQ
gItSLiEk1O7423lIklke2ScynGSP7hf8NWXZcmu97K2o134iiZc0XqyXeBV9
GOtphdOnQyLpwMZTm0XiG3OTdjX94ROLCo6HUIOt9A78JVel8kvmuiyIscON
hBbGiwmZEdpgfc36JtZns+73uDR2sm7sjLjfbbo4o3U9RwCViSl4RCHsjN8f
5aJqp7fN4yXxmoY27W48eZ7auoArF1jBolGIQbZ1VSktKbNkJbeecJpei0q9
v3VbtamLlJkx2AHdAtK9gc83tJqjLlFKHV8bT6jUgouT8iwKK8X+CB4ZVZT1
KZRVPnxzSPmoigSsx0ccIon3/5kl3bHqpmqBVUw+NJ/w++P8xnKSjuSSFsj3
T1R2Rk3df8dPecmJJwy6KwXC5KeIBkmHoWqekQJyIFeLOMmyKPIqvAfoGcQ1
1JlKC15b2YEiUPSDWNzHYn/QRRrUXFZjTLoSrZsb/vsC7k81VIwTu41GvWL7
8+Kl+NvblkkGVZ5senHxo3xbqRjeWCj8p/eOUx821/5u7BA8RCG4n0K93HND
h3odbbPD/MEO9drZjR2q5bAbO+T3dqi9g7epQ+2luU0dam+5bexQfS1tvYOL
sgs5cxHb5lfIzhL5DFpgZVZNKDBbczyn/IbzBn0klbwZGRUJ43Qa3JoXpPl9
94PhwLzsbO0kiy+97LL+TovzDi8d7t3r9+gt5Y0lCNW0UbVELXXvXlsFFvXb
RUI0hU0zKQB0dNnvntfveUOo9ulmZ7R56+6N7Ls8WG1zu5V0P2c1V53q2zZc
uyBqI/qDakG0y9Pdy5CbG1fHx2+YEwSBuXokX+FsidjLcEbODWeWx8beqcmt
6Hvy/d8ZzX/YaqQT2tWJzwhabJr3Z7/hiJnsS5JtMQCBX1S/bYkUxeBtsbOB
1EP1Z24p+aIthneNf7BOw1IxRqEtdn/GQio3NpYKWY622LuXxua8miOAE2yL
xyDwadbCDitsDU79MKA8aqQmNhBpKM+aGMAt3nyt4gv5LEwv5kn04y3EXeez
GZyqmthCK1saS3+iZg3zVaqTagW6pjyX/6KKhUaMt9nfUnYes77yc+MEX+Xx
ZBz5QN32Lw2g8RsQWazkyWdHSZzM5jm3MWBF1Ls0EQ/VL5FjzyqF4B2i/Dq8
ALgO5Vc//V+mA4QJbjBsEJBUBZMTBasxZuih940HOYU9LSZEhBWawho9V0vs
bmLNQe1lV1tpxrbPdSOrqK6MKT1+cfoV9zri66CEX+QzHbhEgAqzx9GK15CG
8rcq/emvsaJV8LqOgHoRq74OCTfyQ4oX0fDTf9Hl1e9XcXBBPGpzA3HwJA1J
45SK1IatUC062UuKOQ6PiuWXNxM+zjPzQ0rYot0s1BP/D8d1DGKfSwAA
</rfc> </rfc>
 End of changes. 173 change blocks. 
800 lines changed or deleted 918 lines changed or added

This html diff was produced by rfcdiff 1.48.