<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.22 (Ruby 3.3.4) --> <?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" number="9741" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.24.0 -->version="3" xml:lang="en" updates="" obsoletes=""> <front> <title abbrev="CDDL: More Control Operators forText ">ConciseText">Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text</title> <seriesInfoname="Internet-Draft" value="draft-ietf-cbor-cddl-more-control-08"/>name="RFC" value="9741"/> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization>Universität Bremen TZI</organization> <address> <postal> <street>Postfach 330440</street> <city>Bremen</city> <code>D-28359</code> <country>Germany</country> </postal> <phone>+49-421-218-63921</phone> <email>cabo@tzi.org</email> </address> </author> <date year="2025"month="January" day="09"/>month="March"/> <area>ART</area> <workgroup>cbor</workgroup> <keyword>Concise Data Definition Language</keyword> <keyword>Control Operator</keyword> <abstract><?line 69?><t>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension pointbothin both an application-specific and a more general way.</t> <t>The present document defines a number of additional generally applicable control operators for text conversion(Bytes, Integers, JSON, Printf-style formatting)(bytes, integers, printf-style formatting, and JSON) and for an operation on text.</t><!-- [^status] [^status]: Revision –00 of this WG draft ... --></abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://cbor-wg.github.io/cddl-more-control/"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-more-control/"/>. </t> <t> Discussion of this document takes place on the Concise Binary Object Representation (CBOR) Maintenance and Extensions Working Group mailing list (<eref target="mailto:cbor@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cbor/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cbor/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/cbor-wg/cddl-more-control"/>.</t> </note></front> <middle><?line 86?><section anchor="intro"> <name>Introduction</name> <t>The Concise Data Definition Language (CDDL), standardized in <xref target="RFC8610"/>, provides "control operators" as its main language extension point (<xref section="3.8" sectionFormat="of" target="RFC8610"/>). RFCs have added to this extension pointbothin both an application-specific <xref target="RFC9090"/> and a more general <xref target="RFC9165"/> way.</t> <t>The present document defines a number of additional generally applicable controloperators:</t>operators. In <xref target="tbl-new"/>, 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"> <name>Summary of New Control Operators inthis Document, t = target type (left-hand side), c = controller type (right-hand side)</name>This Document</name> <thead> <tr> <th align="left">Name</th> <th align="left">t</th> <th align="left">c</th> <th align="left">Purpose</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.b64u</tt>, <tt>.b64c</tt></td> <td align="left">text</td> <td align="left">bytes</td> <td align="left">Base64 representation of byte strings</td> </tr> <tr> <td align="left"> <tt>.b64u-sloppy</tt>, <tt>.b64c-sloppy</tt></td> <td align="left">text</td> <td align="left">bytes</td> <tdalign="left">(sloppy-tolerantalign="left">Sloppy-tolerant variants of theabove)</td>above</td> </tr> <tr> <td align="left"> <tt>.hex</tt>, <tt>.hexlc</tt>, <tt>.hexuc</tt></td> <td align="left">text</td> <td align="left">bytes</td> <td align="left">Base16 representation of byte strings</td> </tr> <tr> <td align="left"> <tt>.b32</tt>, <tt>.h32</tt></td> <td align="left">text</td> <td align="left">bytes</td> <td align="left">Base32 representation of byte strings</td> </tr> <tr> <td align="left"> <tt>.b45</tt></td> <td align="left">text</td> <td align="left">bytes</td> <td align="left">Base45 representation of byte strings</td> </tr> <tr> <td align="left"> <tt>.base10</tt></td> <td align="left">text</td> <td align="left">int</td> <td align="left">Text representation of integer numbers</td> </tr> <tr> <td align="left"> <tt>.printf</tt></td> <td align="left">text</td> <td align="left">array</td> <td align="left">Printf-formatted text representation of data items</td> </tr> <tr> <td align="left"> <tt>.json</tt></td> <td align="left">text</td> <td align="left">any</td> <td align="left">Text representation of JSON values</td> </tr> <tr> <td align="left"> <tt>.join</tt></td> <td align="left">text or bytes</td> <td align="left">array</td> <td align="left">Build text or byte string from array of components</td> </tr> </tbody> </table> <section anchor="terminology"> <name>Terminology</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="BCP14"/> (<xref target="RFC2119"/>) (<xref target="RFC8174"/>)target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>Regular expressions mentioned in the text are as defined in <xref target="RFC9485"/>.</t> <t>This specification uses terminology from <xref target="RFC8610"/>. In particular, with respect to control operators, "target" refers to theleft-hand side operand,left-hand-side operand and "controller" to theright-hand sideright-hand-side operand. "Tool" refers to tools along the lines of that described in <xref section="F" sectionFormat="of" target="RFC8610"/>. Note also that the data model underlying CDDL provides for text strings as well as byte strings as two separate types, which are then collectively referred to as "strings".</t> <t> The term "opinionated" is used in this document to explain that the selection of operators included is somewhat frugal, based on opinions about what the preferred (and likely) usage scenarios will be. Specifically, not including a potential choice doesn’t by itself intend to express that the choice is unacceptable; it might still be added in a future registration if these opinions evolve. </t> </section> </section> <section anchor="text-conversion"> <name>Text Conversion</name> <section anchor="base"> <name>Byte Strings: Base 16 (Hex), Base 32, Base 45, and Base 64</name> <t>A CDDL model often defines data that are byte strings in essence but need to be transported in various encoded forms, such as base64 or hex. This section defines a number of control operators to model these conversions.</t> <t>The control operators generally are of a form that could be used like this:</t> <sourcecode type="cddl" name="example-b64u.cddl"><![CDATA[ signature-for-json = text .b64u signature signature = bytes .cbor COSE_Sign1 ]]></sourcecode> <t>The specification of these control operatorsis complicated bycannot provide full coverage of the large number of transformations inuse. Inspireduse; it focuses on <xref target="RFC4648"/> and additionally <xref target="RFC9285"/>, as shown in <xref target="tbl-text-conv"/>. For the representations defined in <xref target="RFC4648"/>, this specification uses names as inspired by Section <xref target="RFC8949" section="8" sectionFormat="bare"/> of RFC 8949 <xreftarget="STD94"/>, this specification uses representations defined in <xref target="RFC4648"/> with the following names:</t>target="STD94"/>: </t> <table anchor="tbl-text-conv"> <name>Control Operators for Text Conversion of Byte Strings</name> <thead> <tr> <thalign="left">name</th>align="left">Name</th> <thalign="left">meaning</th>align="left">Meaning</th> <thalign="left">reference</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.b64u</tt></td> <tdalign="left">Base64URL,align="left">Base64url, no padding</td> <td align="left"> <xref section="5" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.b64u-sloppy</tt></td> <tdalign="left">Base64URL,align="left">Base64url, no padding, sloppy</td> <td align="left"> <xref section="5" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.b64c</tt></td> <td align="left">Base64 classic, padding</td> <td align="left"> <xref section="4" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.b64c-sloppy</tt></td> <td align="left">Base64 classic, padding, sloppy</td> <td align="left"> <xref section="4" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.b32</tt></td> <td align="left">Base32, no padding</td> <td align="left"> <xref section="6" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.h32</tt></td> <tdalign="left">Base32/hexalign="left">Base32 with "Extended Hex" alphabet, no padding</td> <td align="left"> <xref section="7" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.hex</tt></td> <td align="left">Base16 (hex), either case</td> <td align="left"> <xref section="8" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.hexlc</tt></td> <td align="left">Base16 (hex), lower case</td> <td align="left"> <xref section="8" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.hexuc</tt></td> <td align="left">Base16 (hex), upper case</td> <td align="left"> <xref section="8" sectionFormat="of" target="RFC4648"/></td> </tr> <tr> <td align="left"> <tt>.b45</tt></td> <td align="left">Base45</td> <td align="left"> <xref target="RFC9285"/></td> </tr> </tbody> </table> <t>Note that this specification is somewhat opinionated here: It does not providebase64url, base32base64url orbase32hexbase32(hex) encoding withpadding,padding or base64 classic without padding. Experience indicates that these combinations only ever occur in error, so the usability of CDDL is increased by not providing them in the first place. Also, adding "c" makes sure that any decision for classic base64 is actively taken.</t> <t>These control operators are "strict" in their matching, i.e., they only match base encodings that conform to the mandates of their defining documents. Note that this also means that <tt>.b64u</tt> and <tt>.b64c</tt> only match text strings composed of the set of characters defined for each of them, respectively. (This ismaybeperhaps worth pointing outhereexplicitly asthisit contrasts with the "b64" literal prefix that can be used to notate byte strings in CDDL source code, which simply accepts characters from either alphabet. This behavior is different from the matching behavior of the four base64 control operators defined here.)</t> <t>The additional designation "sloppy" indicates that the text string is not validated for any additional bits being zero, in variance to what is specified in the paragraphbehind tablethat follows Table 1 in <xref section="4" sectionFormat="of" target="RFC4648"/>. Note that the present specification is opinionated again in not specifying a sloppy variant of base32 orbase32/hex,base32hex, as no legacy use of sloppybase32(/hex)base32(hex) was known at the time of writing. Base45 <xref target="RFC9285"/> is known to be suboptimal for use in environments with limited data transparency (such asURLs),URLs) but is included because of its close relationship to QR codes and its wide use in health informatics (note that base45 is strongly specified not to allow sloppy forms of encoding).</t> </section> <section anchor="numerals"> <name>Numerals</name> <table anchor="tbl-num"> <name>Control Operator for Text Conversion of Integers</name> <thead> <tr> <thalign="left">name</th>align="left">Name</th> <thalign="left">meaning</th>align="left">Meaning</th> <thalign="left">reference</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.base10</tt></td> <td align="left">Base-ten (decimal)Integer</td>integer</td> <td align="left">---</td> </tr> </tbody> </table> <t>The control operator <tt>.base10</tt> allows the modeling of text strings that carry an integer number in decimal form (as a text string with digits in the usual base-ten positional numeral system), such as in the uint64/int64 formats of YANG-JSON <xref target="RFC7951"/>.</t> <sourcecode type="cddl" name="example-base10.cddl"><![CDATA[ yang-json-sid = text .base10 (0..9223372036854775807) ]]></sourcecode> <t>Again, the specification is opinionated by only providing for integer numbersand these onlyrepresented without leading zeros, i.e., the decimal integer numerals match the regular expression <tt>0|-?[1-9][0-9]*</tt> (of course, this is further restricted by the control type). Seethe next section<xref target="printf-style-formatting"/> for moreflexibility,flexibility and for other numeric bases such as octal, hexadecimal, or binary conversions.</t> <t>Note that this control operator governs text representations of integers and should not be confused with the control operators governing text representations of byte strings(<tt>b64u</tt> etc.).(such as <tt>.b64u</tt>). This contrast is somewhat reinforced by spelling out "base" in the name<tt>base10</tt><tt>.base10</tt> as opposed to those of the byte string operators.</t> </section> <section anchor="printf-style-formatting"><name>Printf-style<name>Printf-Style Formatting</name> <table anchor="tbl-printf"> <name>Control Operator forPrintf-formattingPrintf-Style Formatting of Data Item(s)</name> <thead> <tr> <thalign="left">name</th>align="left">Name</th> <thalign="left">meaning</th>align="left">Meaning</th> <thalign="left">reference</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.printf</tt></td> <tdalign="left">Printf-formattingalign="left">Printf-style formatting of data item(s)</td> <td align="left">---</td> </tr> </tbody> </table> <t>The control operator <tt>.printf</tt> allows the modeling of text strings that carry various formatted information, as long as the format can be represented inPrintf-styleprintf-style formatting strings as they are used in the C language (see Section7.21.6.17.23.6.1 of <xreftarget="C"/>).</t>target="C"/>; note that the "C23" standard includes %b and %B for formatting into binary digits).</t> <t>The controller (right-hand side) of the <tt>.printf</tt> control is an array of onePrintf-styleprintf-style format string and zero or more data items that fit the individual conversion specifications in the format string. The construct matches a text string representing the textual output of an equivalent C-language <tt>printf</tt> function call thatis givenreceives as arguments the format string and the data items following it in thearray.</t> <t>Fromarray. </t> <t>Out of the functionality described for printfspecificationformatting in Section 7.23.6.1 of the Clanguage,language specification <xref target="C"/>, length modifiers (paragraph 7) are not used and <bcp14>MUST NOT</bcp14> be included in the format string. The's'"s" conversion specifier (paragraph 8) is used to interpolate a text string in UTF-8 form. The'c'"c" conversion specifier (paragraph 8) represents a single Unicode scalar value as a UTF-8 character. The'p'"p" and'n'"n" conversion specifiers (paragraph 8) are not used and <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 <tt>"0x0013"</tt>:</t> <sourcecode type="cddl" name="example-printf.cddl"><![CDATA[ my_alg_19 = hexlabel<19> hexlabel<K> = text .printf (["0x%04x", K]) ]]></sourcecode> <t>The data items in the controller array do not need to be literals, asfor example in:</t>in the following example:</t> <sourcecode type="cddl" name="example-printf-uint.cddl"><![CDATA[ any_alg = hexlabel<1..20> hexlabel<K> = text .printf (["0x%04x", K]) ]]></sourcecode> <t>Here, <tt>any_alg</tt> matches the text strings <tt>"0x0013"</tt> or <tt>"0x0001"</tt> but not <tt>"0x1234"</tt>.</t> </section> <section anchor="json-values"> <name>JSON Values</name> <!-- [rfced] In Section 2.4, would it be helpful to include text introducing/explaining the sourcecode? This is done with sourcecode in other sections. --> <t>Some applications store complete JSON texts <xref target="STD90"/> into textstrings, thestrings. The JSON valuefor whichof these can easily be defined in CDDL by using the default JSON-to-CBOR conversion rules providedbyin Section <xref target="RFC8949" section="6.2" sectionFormat="bare"/> of RFC 8949 <xref target="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"/>.</t> <table anchor="tbl-json"> <name>Control Operator for Text Conversion of JSON Values</name> <thead> <tr> <thalign="left">name</th>align="left">Name</th> <thalign="left">meaning</th>align="left">Meaning</th> <thalign="left">reference</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.json</tt></td> <td align="left">JSON</td> <td align="left"> <xref target="STD90"/></td> </tr> </tbody> </table> <sourcecode type="cddl" name="example-json.cddl"><![CDATA[ embedded-claims = text .json claims claims = {iss: text, exp: text} ]]></sourcecode> <t>Notes:</t> <ul spacing="normal"> <li> <t>JSON has known interoperability problems <xref target="RFC7493"/>. While <xref section="4" sectionFormat="of" target="RFC7493"/> probably is not relevant to this specification, <xref section="2" sectionFormat="of" target="RFC7493"/> provides requirements that need to be followed to make use of the generic data model underlying CDDL. Note that the intention of <xref section="2.2" sectionFormat="of" target="RFC7493"/> is directly supported by Section <xref target="RFC8949" section="6.2" sectionFormat="bare"/> of RFC 8949 <xref target="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> <t>This control operator provides no way to constrain the use of blank space or other serialization variants in the JSON representation of the data items; restrictions on the serialization to specific variants(e.g,(e.g., not providing for the addition of any insignificant blankspace,space and prescribing an order in which map entries are serialized) could be defined in future control operators.</t> </li> <li> <t>A <tt>.jsonseq</tt> is not provided in this document for JSON text sequences <xref target="RFC7464"/>, as no use case for inclusion in CDDL is known at the time of writing; again, future control operators could address this use case.</t> </li> </ul> </section> </section> <section anchor="text-processing"> <name>Text Processing</name> <section anchor="join"> <name>Join</name> <t>Often, text strings need to be constructed out of parts that can best be modeled as an array.</t> <table anchor="tbl-join"> <name>Control Operator for Text Generation from Arrays</name> <thead> <tr> <thalign="left">name</th>align="left">Name</th> <thalign="left">meaning</th>align="left">Meaning</th> <thalign="left">reference</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.join</tt></td> <tdalign="left">concatenatealign="left">Concatenate elements of an array</td> <td align="left">---</td> </tr> </tbody> </table> <t>For example, an IPv4 address in dotted-decimal might be modeled as in <xref target="fig-join-example"/>.</t> <figure anchor="fig-join-example"> <name>Using the .joinoperatorOperator tobuild dotted-decimalBuild Dotted-Decimal IPv4addresses</name>Addresses</name> <sourcecode type="cddl" name="example-join.cddl"><![CDATA[ legacy-ip-address = text .join legacy-ip-address-elements legacy-ip-address-elements = [bytetext, ".", bytetext, ".", bytetext, ".", bytetext] bytetext = text .base10 byte byte = 0..255 ]]></sourcecode> </figure> <t>The elements of the controller array need to be strings (text or byte strings). The control operator matches a data item if that data item is also a string, built by concatenating the strings in the array. The result of this concatenation is of the same kind of string (text or bytes) as the first element of the array. (If there is no element in the array, the <tt>.join</tt> construct matches either kind of empty string, obviously further constrained by the control operator target.) The concatenation is performed on the sequences of bytes in the strings. If the result of the concatenation is a text string, the resulting sequence of bytes only matches the target data item if that result is a valid text string (i.e., validUTF-8; noteUTF-8). Note that in contrast to the algorithm used in Section <xref target="RFC8949" section="3.2.3" sectionFormat="bare"/> of RFC 8949 <xreftarget="STD94"/>target="STD94"/>, there is no needthatfor all individual byte sequences going into the concatenation to constitute valid textstrings).</t>strings.</t> <t>Note that this control operator is hard to validate in the most general case, as this would require full parser functionality. Simple implementation strategies will use array elements with constant values as guideposts ("markers", such as the <tt>"."</tt> in <xref target="fig-join-example"/>) for isolating the variable elements that need further validation at the CDDL data model level.ItTherefore, it isthereforerecommended to limit the use of <tt>.join</tt> to simple arrangements where the array elements are laid out explicitly and there are no adjacent variable elements without intervening constant values, and where these constant values do not occur within the text described by the variableelements.<br/>elements. If more complex parsing functionality is required, the ABNF control operators (see <xref section="3" sectionFormat="of" target="RFC9165"/>) may be useful; however, these cannot reach back into CDDL-specified elements like <tt>.join</tt>can do.</t>can.</t> <aside> <t>Implementation note: A validator implementation can use the marker elements to scan thetext, isolatingtext and isolate the variable elements. It also can build a parsing regexp(<xref section="6" sectionFormat="of" target="RFC9485"/>; see also <xref section="8" sectionFormat="of" target="RFC9485"/> for security considerations related to regexps)from the elements of the controller array, with capture groups for each element, and validate the captures against the elements of the array. (For more about parsing regexps, see <xref section="6" sectionFormat="of" target="RFC9485"/>; see also <xref section="8" sectionFormat="of" target="RFC9485"/> for security considerations related to regexps.) In the most general case, these implementation strategies can exhibit false negatives, where the implementation cannot find the structure that would be successfully validated using the controller; it is <bcp14>RECOMMENDED</bcp14> that implementations provide full coverage at least for the marker-based subset outlined in the previous paragraph.</t> </aside> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t><cref anchor="to-be-removed">RFC Editor: please replace RFC-XXXX<!-- [rfced] FYI - In Section 4, we removed the xref with theRFC number of this RFC and remove this note.</cref></t> <t>This document requestsrelative attribute. IANA has recommended against use of the registry-specific URLs; the web portion of the style guide was recently updated toregistermake this more clear. --> <t>IANA has registered the contents of <xref target="tbl-iana-reqs"/> into theregistry "<xref section="CDDL"CDDL Control Operators"relative="#cddl-control-operators" sectionFormat="bare" target="IANA.cddl"/>"registry of <xreftarget="IANA.cddl"/>:</t>target="IANA.cddl"/>: </t> <table anchor="tbl-iana-reqs"> <name>New ControlOperators To Be Registered</name>Operators</name> <thead> <tr> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left"> <tt>.b64u</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.b64u-sloppy</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.b64c</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.b64c-sloppy</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.b45</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.b32</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.h32</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.hex</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.hexlc</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.hexuc</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.base10</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.printf</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.json</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> <tr> <td align="left"> <tt>.join</tt></td> <tdalign="left">[RFC-XXXX]</td>align="left">RFC 9741</td> </tr> </tbody> </table> </section> <sectionremoveInRFC="true" anchor="implementation-status"> <name>Implementation Status</name> <!-- RFC7942 --> <t>In the CDDL tool described in <xref section="F" sectionFormat="of" target="RFC8610"/>, the control operators defined in the present revision of this specification are implemented as of version 0.10.4.</t> </section> <sectionanchor="security-considerations"> <name>Securityconsiderations</name>Considerations</name> <t>The security considerations in <xref section="5" sectionFormat="of" target="RFC8610"/>apply, as well as those in <xref section="12" sectionFormat="of" target="RFC4648"/>apply. In addition, for the control operators defined in <xreftarget="base"/>.</t>target="base"/>, the security considerations in <xref section="12" sectionFormat="of" target="RFC4648"/> apply.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/std90"> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259"> <front> <title>The JavaScript Object Notation (JSON) Data Interchange Format</title> <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/> <date month="December" year="2017"/> <abstract> <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t> </abstract> </front> <seriesInfo name="STD" value="90"/> <seriesInfo name="RFC" value="8259"/> <seriesInfo name="DOI" value="10.17487/RFC8259"/> </reference> </referencegroup> <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94"> <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949"> <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 format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> </referencegroup> <reference anchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="C. Vigano" initials="C." surname="Vigano"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2019"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.94.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.90.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <reference anchor="IANA.cddl" target="https://www.iana.org/assignments/cddl"> <front> <title>Concise Data Definition Language (CDDL)</title> <author> <organization>IANA</organization> </author> </front> </reference><reference anchor="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>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</t> <t>The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance.</t> </abstract> </front> <seriesInfo name="RFC" value="9165"/> <seriesInfo name="DOI" value="10.17487/RFC9165"/> </reference> <reference anchor="RFC4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <date month="October" year="2006"/> <abstract> <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference> <reference anchor="RFC9285"> <front> <title>The Base45 Data Encoding</title> <author fullname="P. Fältström" initials="P." surname="Fältström"/> <author fullname="F. Ljunggren" initials="F." surname="Ljunggren"/> <author fullname="D.W. van Gulik" initials="D.W." surname="van Gulik"/> <date month="August" year="2022"/> <abstract> <t>This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.</t> </abstract> </front> <seriesInfo name="RFC" value="9285"/> <seriesInfo name="DOI" value="10.17487/RFC9285"/> </reference> <reference anchor="RFC9485"> <front> <title>I-Regexp: An Interoperable Regular Expression Format</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="T. Bray" initials="T." surname="Bray"/> <date month="October" year="2023"/> <abstract> <t>This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries.</t> </abstract> </front> <seriesInfo name="RFC" value="9485"/> <seriesInfo name="DOI" value="10.17487/RFC9485"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9165.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9285.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9485.xml"/> <reference anchor="C"target="https://www.iso.org/standard/74528.html">target="https://www.iso.org/standard/82075.html"> <front> <title>Information technology—- Programming languages—- C</title> <author> <organization>International Organization for Standardization</organization> </author> <dateyear="2018" month="June"/>year="2024" month="October"/> </front> <seriesInfo name="ISO/IEC"value="9899:2018"/> <annotation> <!-- work around broken annotation content model --> Technicallyvalue="9899:2024"/> <annotation>Technically equivalent specification text is available at <ereftarget="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>target="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf" brackets="angle"/>.</annotation> <refcontent>Fourth Edition</refcontent> </reference><referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> </referencegroup><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC7464"> <front> <title>JavaScript Object Notation (JSON) Text Sequences</title> <author fullname="N. Williams" initials="N." surname="Williams"/> <date month="February" year="2015"/> <abstract> <t>This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).</t> </abstract> </front> <seriesInfo name="RFC" value="7464"/> <seriesInfo name="DOI" value="10.17487/RFC7464"/> </reference> <reference anchor="RFC7493"> <front> <title>The I-JSON Message Format</title> <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/> <date month="March" year="2015"/> <abstract> <t>I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t> </abstract> </front> <seriesInfo name="RFC" value="7493"/> <seriesInfo name="DOI" value="10.17487/RFC7493"/> </reference> <reference anchor="RFC9090"> <front> <title>Concise Binary Object Representation (CBOR) Tags for Object Identifiers</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="July" year="2021"/> <abstract> <t>The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.</t> <t>This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.</t> </abstract> </front> <seriesInfo name="RFC" value="9090"/> <seriesInfo name="DOI" value="10.17487/RFC9090"/> </reference> <reference anchor="RFC7951"> <front> <title>JSON Encoding of Data Modeled with YANG</title> <author fullname="L. Lhotka" initials="L." surname="Lhotka"/> <date month="August" year="2016"/> <abstract> <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t> </abstract> </front> <seriesInfo name="RFC" value="7951"/> <seriesInfo name="DOI" value="10.17487/RFC7951"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7464.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9090.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/> </references> </references><?line 462?><section numbered="false" anchor="list-of-figures"> <name>List of Figures</name><ol spacing="normal" type="1"><li><t><xreftarget="fig-join-example">Using the .join operator to build dotted-decimal IPv4 addresses</xref></t> </li> </ol>target="fig-join-example"/>: <xref target="fig-join-example" format="title"></xref></t> </section> <section numbered="false" anchor="list-of-tables"> <name>List of Tables</name><ol spacing="normal" type="1"><li><t><xreftarget="tbl-new">Summary of New Control Operators in this Document</xref></t> </li> <li>target="tbl-new"></xref>: <xref target="tbl-new" format="title"></xref></t> <t><xreftarget="tbl-text-conv">Control Operators for Text Conversion of Byte Strings</xref></t> </li> <li>target="tbl-text-conv"></xref>: <xref target="tbl-text-conv" format="title"></xref></t> <t><xreftarget="tbl-num">Control Operator for Text Conversion of Integers</xref></t> </li> <li>target="tbl-num"></xref>: <xref target="tbl-num" format="title"></xref></t> <t><xreftarget="tbl-printf">Control Operator for Printf-formatting of Data Item(s)</xref></t> </li> <li>target="tbl-printf"></xref>: <xref target="tbl-printf" format="title"></xref></t> <t><xreftarget="tbl-json">Control Operator for Text Conversion of JSON Values</xref></t> </li> <li>target="tbl-json"></xref>: <xref target="tbl-json" format="title"></xref></t> <t><xreftarget="tbl-join">Control Operator for Text Generation from Arrays</xref></t> </li> <li>target="tbl-join"></xref>: <xref target="tbl-join" format="title"></xref></t> <t><xreftarget="tbl-iana-reqs">New Control Operators To Be Registered</xref></t> </li> </ol>target="tbl-iana-reqs"></xref>: <xref target="tbl-iana-reqs" format="title"></xref></t> </section> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t><contact fullname="Henk Birkholz"/> suggested the need for many of the control operators defined here. The author would like to thank <contact fullname="Laurence Lundblade"/> and <contact fullname="Jeremy O'Donoghue"/> for sharpening some of the mandates, <contact fullname="Mikolai Gütschow"/> for improvements to some examples, <contact fullname="A.J. Stein"/> for serving as shepherd for this document and for his shepherd review, the IESG and Directorate reviewers (notably <contact fullname="Ari Keränen"/>, <contact fullname="Darrel Miller"/>, and <contact fullname="Éric Vyncke"/>), and <contact fullname="Orie Steele"/> for serving as responsible AD and for providing a detailed AD review.</t> </section> </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>