<?xmlversion='1.0' encoding='utf-8'?>version="1.0" 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-rfc2629 version 1.5.12 --> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc compact="yes"?> <?rfc comments="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cbor-cddl-control-07"category="std" consensus="true"number="9165" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.9.1 --> <front> <title abbrev="CDDLcontrol operators">AdditionalControl Operators">Additional Control Operators forCDDL</title>the Concise Data Definition Language (CDDL)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-cbor-cddl-control-07"/>name="RFC" value="9165"/> <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="2021"month="October" day="22"/> <keyword>Internet-Draft</keyword>month="December"/> <keyword>binary format</keyword> <keyword>data interchange format</keyword> <keyword>description language</keyword> <keyword>schema language</keyword> <keyword>tree grammar</keyword> <keyword>ABNF</keyword> <keyword>Augmented BNF</keyword> <keyword>feature indication</keyword> <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: <tt>.plus</tt>,<tt>.cat</tt><tt>.cat</tt>, and <tt>.det</tt> for the construction ofconstants,constants; <tt>.abnf</tt>/<tt>.abnfb</tt> for including ABNF (RFC5234/RFC5234 and RFC 7405) in CDDLspecifications,specifications; and <tt>.feature</tt> for indicating the use of a non-basic feature in an instance.</t> </abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t>The Concise Data Definition Language (CDDL), standardized in <xref target="RFC8610" format="default"/>, provides "control operators" as its main language extension point (<xref section="3.8" sectionFormat="of" target="RFC8610" format="default"/>).</t> <t>The present document defines a number of control operators that were not yet ready at the timeRFC 8610<xref target="RFC8610"/> was completed:</t> <table anchor="tbl-new" align="center"> <name>Newcontrol operatorsControl Operators in thisdocument</name>Document</name> <thead> <tr> <th align="left">Name</th> <th align="left">Purpose</th> </tr> </thead> <tbody> <tr> <td align="left">.plus</td> <td align="left">Numeric addition</td> </tr> <tr> <td align="left">.cat</td> <td align="left">StringConcatenation</td>concatenation</td> </tr> <tr> <td align="left">.det</td> <td align="left">StringConcatenation,concatenation, pre-dedenting</td> </tr> <tr> <td align="left">.abnf</td> <td align="left">ABNF in CDDL (text strings)</td> </tr> <tr> <td align="left">.abnfb</td> <td align="left">ABNF in CDDL (byte strings)</td> </tr> <tr> <td align="left">.feature</td> <tdalign="left">Indicatealign="left">Indicates name of feature used (extension point)</td> </tr> </tbody> </table> <section anchor="terminology" numbered="true" toc="default"> <name>Terminology</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119" format="default"/>target="RFC2119"/> <xreftarget="RFC8174" format="default"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This specification uses terminology from <xref target="RFC8610" format="default"/>. In particular, with respect to control operators, "target" refers to the left-hand sideoperand,operand and "controller" to the right-hand side operand. "Tool" refers to tools along the lines of that described in <xref section="F" sectionFormat="of" target="RFC8610" format="default"/>. 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 termABNF"ABNF" in this specification stands for the combination of <xref target="RFC5234" format="default"/> and <xref target="RFC7405"format="default"/>,format="default"/>; i.e., the ABNF control operators defined by this document allow use of the case-sensitive extensions defined in <xref target="RFC7405" format="default"/>.</t> </section> </section> <section anchor="computed-literals" numbered="true" toc="default"> <name>Computed Literals</name> <t>CDDL as defined in <xref target="RFC8610" format="default"/> does not have any mechanisms to compute literals. To cover a large part of the use cases, this specification adds three control operators: <tt>.plus</tt> for numeric addition, <tt>.cat</tt> for string concatenation, and <tt>.det</tt> for string concatenation with dedenting of both sides (target and controller).</t> <t>For these operators, as with all control operators, targets and controllers are types. The resulting type is therefore formally a function of the elements of the cross-product of the two types. Not all tools may be able to work with non-unique targets or controllers.</t> <section anchor="numeric-addition" numbered="true" toc="default"> <name>Numeric Addition</name> <t>In manycases in a specification,cases, numbers are needed relative to a basenumber.number in a specification. The <tt>.plus</tt> control identifies a number that is constructed by adding the numeric values of the target andofthe controller.</t><t>Target<t>The target and controllerMUSTboth <bcp14>MUST</bcp14> be numeric. If the target is a floating point number and the controller an integer number, or vice versa, the sum is converted into the type of the target; converting from a floating point number to an integer selects its floor (the largest integer less than or equal to the floating point number, i.e., rounding towards negative infinity).</t> <figure anchor="exa-plus"><name>Example: addition<name>An Example of Addition to abase value</name>Base Value</name> <sourcecode type="cddl"><![CDATA[ interval<BASE> = ( BASE => int ; lower bound (BASE .plus 1) => int ; upper bound ? (BASE .plus 2) => int ; tolerance ) X = 0 Y = 3 rect = { interval<X> interval<Y> } ]]></sourcecode> </figure> <t>The example in <xref target="exa-plus" format="default"/> contains the generic definition of a CDDL group <tt>interval</tt> that gives a lower andanupper boundand optionallyand, optionally, a tolerance. The parameter BASE allows the non-conflicting use of a multiple of these interval groups in onemap,map by assigning different labels to the entries of the interval. The rule <tt>rect</tt> combines two of these interval groups into a map, one group for the X dimension (using 0, 1, and 2 as labels) and one for the Y dimension (using 3, 4, and 5 as labels).</t> </section> <section anchor="string-concatenation" numbered="true" toc="default"> <name>String Concatenation</name> <t>It is often useful to be able to compose string literals out of component literals defined in different places in the specification.</t> <t>The <tt>.cat</tt> control identifies a string that is built from a concatenation of the target and the controller.TargetThe target and controllerMUSTboth <bcp14>MUST</bcp14> be strings. The result of the operation has the same typeofas the target. The concatenation is performed on the bytes in both strings. If the target is a text string, the result of that concatenationMUST<bcp14>MUST</bcp14> be valid UTF-8.</t> <figure anchor="exa-cat"><name>Example: concatenation<name>An Example oftextConcatenation of Text andbyte string</name>Byte Strings</name> <sourcecode type="cddl"><![CDATA[ac = "foo" .cat ' bar baz ' ; on a system where the newline is \n, is the same string as: b = "foo\n bar\n baz\n" ]]></sourcecode> </figure> <t>The example in <xref target="exa-cat" format="default"/> builds a text string named<tt>a</tt> out of<tt>c</tt> from concatenating the target text string <tt>"foo"</tt> and the controller byte string entered in a text form byte string literal. (This particular idiom is useful when the text string contains newlines, which, as shown in the example for <tt>b</tt>, may be harder to read when entered in the format that the pure CDDL text string notation inherits from JSON.)</t> </section> <section anchor="string-concatenation-with-dedenting" numbered="true" toc="default"> <name>String Concatenation with Dedenting</name> <t>Multi-line string literals for various applications, including embedded ABNF (<xref target="embedded-abnf" format="default"/>), need to be set flush left, at least partially. Often, having some indentation in the source code for the literal can promote readability, as in <xref target="exa-det" format="default"/>.</t> <figure anchor="exa-det"><name>Example: dedenting concatenation</name><name>An Example of Dedenting Concatenation</name> <sourcecode type="cddl"><![CDATA[ oid = bytes .abnfb ("oid" .det cbor-tags-oid) roid = bytes .abnfb ("roid" .det cbor-tags-oid) cbor-tags-oid = ' oid = 1*arc roid = *arc arc = [nlsb] %x00-7f nlsb = %x81-ff *%x80-ff ' ]]></sourcecode> </figure> <t>The control operator <tt>.det</tt> works like <tt>.cat</tt>, except that both arguments (target and controller) are independently <em>dedented</em> before the concatenation takes place.</t> <t>For the first rule in <xref target="exa-det" format="default"/>, the result is equivalent to <xref target="exa-det-result" format="default"/>.</t> <figure anchor="exa-det-result"> <name>Dedentingexample: resultExample: Result offirstFirst .det</name> <sourcecode type="cddl"><![CDATA[ oid = bytes .abnfb 'oid oid = 1*arc roid = *arc arc = [nlsb] %x00-7f nlsb = %x81-ff *%x80-ff ' ]]></sourcecode> </figure> <t>For the purposes of this specification, we definededenting"dedenting" as:</t> <ol spacing="normal" type="1"><li>determining the smallest amount ofleft-mostleftmost blank space (number of leading space characters) present in all the non-blank lines, and</li> <li>removing exactly that number of leading space characters from each line. For blank (blank space only or empty) lines, there may belessfewer (or no) leading space characters than this amount, in which case all leading space is removed.</li> </ol> <t>(The name <tt>.det</tt> is a shortcut for "dedenting cat". The maybe more obvious name <tt>.dedcat</tt> has not been chosen as it is longer and may invoke unpleasant images.)</t> <t>Occasionally, dedenting of only a single item is needed. This can be achieved by using this operator with an empty string, e.g., <tt>"" .det rhs</tt> or <tt>lhs .det ""</tt>, which can in turn be combined with a <tt>.cat</tt>: in the construct <tt>lhs .cat ("" .det rhs)</tt>, only <tt>rhs</tt> is dedented.</t> </section> </section> <section anchor="embedded-abnf" numbered="true" toc="default"> <name>Embedded ABNF</name> <t>Many IETF protocols define allowable values for their text strings in ABNF <xref target="RFC5234" format="default"/> <xref target="RFC7405" format="default"/>. It is often desirable to define a text string type in CDDL by employing existing ABNF embedded into the CDDL specification. Without specific ABNF support in CDDL, that ABNF would usually need to be translated into a regular expression (if that is even possible).</t> <t>ABNF is added to CDDL in the same way that regular expressions were added: by defining a <tt>.abnf</tt> control operator. The target is usually <tt>text</tt> or some restriction on it, and the controller is the text of an ABNF specification.</t> <t>There are several smallissues, withissues; the solutions are given here:</t> <ul spacing="normal"> <li>ABNF can be used to define byte sequences as well as UTF-8 text strings interpreted as Unicode scalar sequences. This means this specification defines two control operators: <tt>.abnfb</tt> for ABNF denoting byte sequences and <tt>.abnf</tt> for denoting sequences of Unicode scalar values(codepoint)(code points) represented as UTF-8 text strings. Both control operators can be applied to targets of either string type; the ABNF is applied to the sequence of bytes in the stringinterpreting thatand interprets it as a sequence of bytes (<tt>.abnfb</tt>) or as a sequence of code points represented as an UTF-8 text string (<tt>.abnf</tt>). The controller stringMUST<bcp14>MUST</bcp14> be a string. When a byte string, it <bcp14>MUST</bcp14> be valid UTF-8 and is interpreted as the textstring.</li>string that has the same sequence of bytes.</li> <li>ABNF defines a list of rules, not a single expression (called "elements" in <xref target="RFC5234" format="default"/>). This is resolved by requiring the controller string to be one valid "element", followed by zero or more valid"rule""rules" separated from the element by a newline;sothus, the controller string can be built by preceding a piece of valid ABNF by an "element" that selects from that ABNF and a newline.</li> <li>For the same reason, ABNF requires newlines; specifying newlines in CDDL text strings is tedious (and leads to essentially unreadable ABNF). The workaround employs the <tt>.cat</tt> operator introduced in <xref target="string-concatenation" format="default"/> and the syntax for text in byte strings. As is customary for ABNF, the syntax of ABNF itself(NOT(<em>not</em> the syntax expressed in ABNF!) is relaxed to allow a singlelinefeedline feed as a newline:</li> </ul> <sourcecode type="abnf"><![CDATA[ CRLF = %x0A / %x0D.0A ]]></sourcecode> <ul spacing="normal"> <li>One set of rules provided in an ABNF specification is often used in multiple positions,in particularparticularly staples such as DIGIT and ALPHA. (Note that all rules referenced need to be defined in each ABNF operator controller string -- there is no implicit import of core ABNF rules from <xref target="RFC5234" format="default"/>Core ABNFor other rules.) The composition this calls for can be provided by the <tt>.cat</tt>operator,operator and/or by <tt>.det</tt> if there is indentation to be disposed of.</li> </ul> <t>These points are combined into an example in <xref target="exa-abnf" format="default"/>, which uses ABNF from <xref target="RFC3339" format="default"/> to specify one of each of theCBORConcise Binary Object Representation (CBOR) tags defined in <xref target="RFC8943" format="default"/> and <xref target="RFC8949" format="default"/>.</t> <figure anchor="exa-abnf"><name>Example: employing<name>An Example of Employing ABNF from RFC 3339ABNFfordefiningDefining CBOR Tags</name><artwork name="" type="" align="left" alt=""><![CDATA[<sourcecode type="cddl"><![CDATA[ ; for RFC 8943 Tag1004 = #6.1004(text .abnf full-date) ; for RFC 8949 Tag0 = #6.0(text .abnf date-time) full-date = "full-date" .cat rfc3339 date-time = "date-time" .cat rfc3339 ; Note the trick of idiomatically starting with a newline, separating ; off the element in the concatenations above from the rule-list rfc3339 = ' date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap sec ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset date-time = full-date "T" full-time ' .det rfc5234-core rfc5234-core = ' DIGIT = %x30-39 ; 0-9 ; abbreviated here ']]></artwork>]]></sourcecode> </figure> </section> <section anchor="features" numbered="true" toc="default"> <name>Features</name> <t>Commonly, the kind of validation enabled by languages such as CDDL provides a Boolean result:valid,valid or invalid.</t> <t>In rapidly evolving environments, this is too simplistic. The data models described by a CDDL specification may continually be enhanced by additional features, and it would be useful even for a specification that does not yet describe a specific future feature to identify the extension point the feature canuse, acceptinguse and accept such extensions while marking them assuch.</t>extensions.</t> <t>The <tt>.feature</tt> control annotates the target as making use of the feature named by the controller. The latter will usually be a string. A tool that validates an instance against that specification may mark the instance as using a feature that is annotated by the specification.</t> <t>More specifically, the tool's diagnostic output might contain the controller (right-hand side) as a featurename,name and the target (left-hand side) as a feature detail. However, in some cases, the target has too much detail, and the specification might want to hint to the tool that more limited detail is appropriate. In this case, the controller should be an array, with the first element being the feature name (that would otherwise be the entirecontroller),controller) and the second element being the detail (usually another string), as illustrated in <xref target="exa-feat-array" format="default"/>.</t> <figure anchor="exa-feat-array"> <name>Providingexplicit detailExplicit Detail with .feature</name> <sourcecode type="cddl"><![CDATA[ foo = { kind: bar / baz .feature (["foo-extensions", "bazify"]) } bar = ... baz = ... ; complex stuff that doesn't all need to be in the detail ]]></sourcecode> </figure> <t><xref target="exa-feat-map" format="default"/> shows what could be the definition of a person, with potential extensions beyond <tt>name</tt> and <tt>organization</tt> being marked <tt>further-person-extension</tt>. Extensions that are known at the time this definition is written can be collected into <tt>$$person-extensions</tt>. However, future extensions would be deemed invalid unless the wildcard at the end of the map is added. These extensions could then be specifically examined by a user or a tool that makes use of the validation result; the label (map key) actually used makes a fine feature detail for the tool's diagnostic output.</t> <t>Leaving out the entire extension point would mean that instances that make use of an extension would be marked aswhole-salewholesale invalid, making the entire validation approach much less useful. Leaving the extension pointin,in but not marking its use asspecial,special would render mistakessuch(such as using the label "<tt>organisation</tt>" instead of"<tt>organization</tt>""<tt>organization</tt>") invisible.</t> <figure anchor="exa-feat-map"> <name>MapextensibilityExtensibility with .feature</name> <sourcecode type="cddl"><![CDATA[ person = { ? name: text ? organization: text $$person-extensions * (text .feature "further-person-extension") => any } $$person-extensions //= (? bloodgroup: text) ]]></sourcecode> </figure> <t><xref target="exa-feat-type" format="default"/> shows another example where <tt>.feature</tt> provides for type extensibility.</t> <figure anchor="exa-feat-type"> <name>TypeextensibilityExtensibility with .feature</name> <sourcecode type="cddl"><![CDATA[ allowed-types = number / text / bool / null / [* number] / [* text] / [* bool] / (any .feature "allowed-type-extension") ]]></sourcecode> </figure> <t>A CDDL tool may simply report the set of features being used; the control then only provides information to the process requesting the validation. One could also imagine a tool that takesargumentsarguments, allowing the tool to accept certain features and reject others (enable/disable). The latter approachcouldcould, forinstanceinstance, be used for a JSON/CBOR switch, as illustrated in <xref target="exa-feat-variants" format="default"/>, usingSenMLSensor Measurement Lists (SenML) <xref target="RFC8428" format="default"/> as the example data model used with both JSON and CBOR.</t> <figure anchor="exa-feat-variants"> <name>DescribingvariantsVariants with .feature</name> <sourcecode type="cddl"><![CDATA[ SenML-Record = { ; ... ? v => number ; ... } v = JC<"v", 2> JC<J,C> = J .feature "json" / C .feature "cbor" ]]></sourcecode> </figure> <t>It remains to be seen if the enable/disable approach can lead to new idioms of using CDDL. The language currently has no way to enforce mutually exclusive use of features, as would be needed in this example.</t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name><t>This document requests IANA to register<t>IANA has registered the contents of <xref target="tbl-iana-reqs" format="default"/> into theregistry "<xref section="CDDL"CDDL Control Operators"relative="#cddl-control-operators" sectionFormat="bare" target="IANA.cddl" format="default"/>"registry of <xref target="IANA.cddl" format="default"/>:</t> <table anchor="tbl-iana-reqs" align="center"> <name>Newcontrol operators to be registered</name>Control Operators</name> <thead> <tr> <th align="left">Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">.plus</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> <tr> <td align="left">.cat</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> <tr> <td align="left">.det</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> <tr> <td align="left">.abnf</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> <tr> <td align="left">.abnfb</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> <tr> <td align="left">.feature</td> <tdalign="left">[RFCthis]</td>align="left">RFC 9165</td> </tr> </tbody> </table> </section> <sectionremoveInRFC="true" anchor="implementation-status" numbered="true" toc="default"> <name>Implementation Status</name> <!-- RFC7942 --> <t>An early implementation of the control operator <tt>.feature</tt> has been available in the CDDL tool described in <xref section="F" sectionFormat="of" target="RFC8610" format="default"/> since version 0.8.11. The validator warns about each feature being used and provides the set of target values used with the feature. The other control operators defined in this specification are also implemented as of version 0.8.21 and 0.8.26 (double-handed <tt>.det</tt>).</t> <t>Andrew Weiss' <xref target="CDDL-RS" format="default"/> has an ongoing implementation of this draft which is feature-complete except for the ABNF and dedenting support (<eref target="https://github.com/anweiss/cddl/pull/79">https://github.com/anweiss/cddl/pull/79</eref>).</t> </section> <sectionanchor="security-considerations" numbered="true" toc="default"> <name>Securityconsiderations</name>Considerations</name> <t>The security considerations of <xref target="RFC8610" format="default"/> apply.</t> <t>While both <xref target="RFC5234" format="default"/> and <xref target="RFC7405" format="default"/> state that security is truly believed to be irrelevant to the respective document, the use of formal description techniques cannot onlysimplify,simplify but sometimes also complicate a specification. This can lead to security problems in implementations and in the specification itself. As with CDDL itself, ABNF should be judiciously applied, and overly complex (or "cute") constructions should be avoided.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC8610" target="https://www.rfc-editor.org/info/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"> <organization/> </author> <author fullname="C. Vigano" initials="C." surname="Vigano"> <organization/> </author> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/> </author> <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://xml2rfc.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> <date/> </front> </reference><reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"> <organization/> </author> <author fullname="P. Overell" initials="P." surname="Overell"> <organization/> </author> <date month="January" year="2008"/> <abstract> <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="68"/> <seriesInfo name="RFC" value="5234"/> <seriesInfo name="DOI" value="10.17487/RFC5234"/> </reference> <reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7405"> <front> <title>Case-Sensitive String Support in ABNF</title> <author fullname="P. Kyzivat" initials="P." surname="Kyzivat"> <organization/> </author> <date month="December" year="2014"/> <abstract> <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t> </abstract> </front> <seriesInfo name="RFC" value="7405"/> <seriesInfo name="DOI" value="10.17487/RFC7405"/> </reference> <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"> <organization/> </author> <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"> <organization/> </author> <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><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name><reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8428"> <front> <title>Sensor Measurement Lists (SenML)</title> <author fullname="C. Jennings" initials="C." surname="Jennings"> <organization/> </author> <author fullname="Z. Shelby" initials="Z." surname="Shelby"> <organization/> </author> <author fullname="J. Arkko" initials="J." surname="Arkko"> <organization/> </author> <author fullname="A. Keranen" initials="A." surname="Keranen"> <organization/> </author> <author fullname="C. Bormann" initials="C." surname="Bormann"> <organization/> </author> <date month="August" year="2018"/> <abstract> <t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t> </abstract> </front> <seriesInfo name="RFC" value="8428"/> <seriesInfo name="DOI" value="10.17487/RFC8428"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.xml"/> <!-- <reference anchor="CDDL-RS" target="https://github.com/anweiss/cddl"> <front> <title>cddl-rs</title> <author initials="A." surname="Weiss" fullname="Andrew Weiss"> <organization/> </author><date>n.d.</date> </front> </reference> <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339"> <front> <title>Date and Time on the Internet: Timestamps</title> <author fullname="G. Klyne" initials="G." surname="Klyne"> <organization/> </author> <author fullname="C. Newman" initials="C." surname="Newman"> <organization/> </author> <date month="July" year="2002"/> <abstract> <t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t> </abstract> </front> <seriesInfo name="RFC" value="3339"/> <seriesInfo name="DOI" value="10.17487/RFC3339"/> </reference> <reference anchor="RFC8943" target="https://www.rfc-editor.org/info/rfc8943"> <front> <title>Concise Binary Object Representation (CBOR) Tags for Date</title> <author fullname="M. Jones" initials="M." surname="Jones"> <organization/> </author> <author fullname="A. Nadalin" initials="A." surname="Nadalin"> <organization/> </author> <author fullname="J. Richter" initials="J." surname="Richter"> <organization/> </author> <date month="November" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR), as specified in RFC 7049, 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>In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.</t> </abstract> </front> <seriesInfo name="RFC" value="8943"/> <seriesInfo name="DOI" value="10.17487/RFC8943"/> </reference> <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"> <organization/> </author> <author fullname="P. Hoffman" initials="P." surname="Hoffman"> <organization/> </author> <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><date/> </front><seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/></reference> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8943.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> </references> </references> <section numbered="false" anchor="acknowledgements" toc="default"> <name>Acknowledgements</name><t>Jim Schaad<t><contact fullname="Jim Schaad"/> suggested several improvements. The <tt>.feature</tt> feature was developed out of a discussion withHenk Birkholz. Paul Kyzivat<contact fullname="Henk Birkholz"/>. <contact fullname="Paul Kyzivat"/> helped isolate the need for <tt>.det</tt>.</t> <t>.det is an abbreviation for "dedenting cat", but Det is also the name of a German TVCartooncartoon character created in the 1960s.</t><!-- LocalWords: dedenting dedented --></section> </back><!-- ##markdown-source: H4sIANhecmEAA8Vc65Ibx3X+30/Rhu0iQANY7EUSiRWpLJekRYW3kKvIsqwK GjONxXgHM/BcdgmuNpWHyAPkR54keZM8Sc53TvdMDwCKqUqqwrIFYKYvp8/9 1jsajVSVVKmd6sdK67M4Tqokz0yqz/OsKvJUv1nbwlR5UepFXujzp09fKjOf F/Z6yj905MblfpyK8ygzK1oxLsyiGiW2WoyieV6MojhOR278KDWVLSsV08dU H02ODkeHk9HRkVJlZbL4n0yaZ/SiKmqrVLIu+GtZHU0mDydH6spubvIinuoX WWWLzFajp9hLRaaa6rKKFe1S2qysS7/EOpnqn6o8GuoyL6rCLkr6tlnJlyhf rU1U8ZeVzaryZ6VMXS3zYkpIGdH/tU4yWut8rJ/kxcpkGT+TY56boqxs1nmT F5dT/X2WXNuiTKr//PdKPyksLa0v/vyCB5QEgyVg3+ZltTDRUh8fT05OJvwu SqrN1E2QB3lM+zwdHT04/uKhe1ITGmnUHy023fDD9ZJx9oeTh6MTwufR4YPR l8cPjw75pV2ZJJ3qyMzzv6s+JmOCUCmVAeaKwMRB3z0/f/Dl4YQGEaHo94uz 12djfHcvvzg6PplqM88W8vurk8kX8vtIJdlie6mTowdEDJutsBZ4ZfTu/ZRh cRzH/EAMg0ctulvEnmVxYW/0DzYpZVBliksgbVlV63J6cHCZVMt6PiaqHZjs BsMOGHSlRqMRAUZIJrIqdbG04OcoKa1+aiqjn9pFkjGn65cmu6zNpdV9gDgg rgD/mSJOPtqYqI6jaKBlqNZFfp3EttS9HabvaVPqpCo1YTnTqV/TfiDGKLHN Ok+yaiygrAtLaKk0CUq94i8Ah9Y1OqtXc1vofLErV7pamkrf2MIS1Sq9sZUu rIk3mp5WtGqVrGwDrL4heMDWqa1sPFWz8Tqty9lQz8YkIzNNR6SvsaWvEGvM h8iQrESMFQEAqKjKIc0GkWcH8jmXOUkWpXWcZJf67Mnr57qPrcEhB/gC1hgA e6wjyrWNkkVCO9PaJG+0O625sKaqC+tXi/k9LQdgaqIUwUAIybPR3JRJpN1w LGoyiCMBF9mxI/YqIcKTnL8A1mJ3Cvfv9rcJnt6pR8G//yVX3N6yOru7+z9g C9W/vX1vBeTj8QMc3C0++P/jGPWLfk1SyAj8Rb+ti3VeWv35f7/QRGY2mfia 4C2IesZZls9MJBZwO76vCjADCEQmIjOfnswTiZV/ZeIQGBzFNibc4WUwERwt E5mNPcv2KyIStDQNLwf7dmRR2DNxvqnsr070jPwLWS9mesv6DiT0r4j9Y93f YpMBTb+d6t9W83SUkV5kLfqo95q+7pKewKmWSdlwTO+OOIlsRZLlaX65gcz4 f8JiZFI1bCqx8avv31/0hvKpX7/h7++e/cP3L949e4rv7789e/my+aLciPff vvn+5dP2Wzvz/M2rV89eP5XJ9FR3Hqneq7Mfe6wUdO/N24sXb16fveztHEAb wkuV6zk0ABl9IijxKcmXItGLimQucvnk/O1//NvhCcnnb4izjw4PH97duR8P Dr86oR83S5vJbnmWbtxPEoeNMuu1NQUrmDQlS7lOKpNCXZW6XOY3mV6SKEHh XACwjlIDxUjeWgTrRZGvWi0xJsWk16aokqhOTTHUN2S6SBqxSIVj7VCQUCXm rkfDFhbSnCtIbWrJqVoC/pK0jkzIYoc/t0xqix5WxfgiuVzumTBWvYs8T4PV 6X95SiqFPC9RwimrGGJL1iMdNN/enhGyiH0/6OeBvhqr1zmxM2Etl0lYJoZu XZELk+o6i22Rblg+ISyN6mQjRPyunOAA5zeWqECfoUDhd3WTk1tByITkVJu1 JVzdLBPyoYhFgKKMsEkoiOCMEIX5gAXBTUek6T23VM/pVhCtEeFql7Ks+cvA TK7miVNH+ULd3jrHiDgLKObfsH5kGXQytmPmLVl/V0pFjcd0RLXF7Gma33gr yNua0o7g0iY4VWtB2jWSTAWb0+HOSZnXkJGXCZ2RaNKxf84IMhlMuErLtAQO kQamY2loT3Iz9cpGxElJuSqFaXkHlboNxlpf4Cl5vWSZUrAvM70/BM6Dg5TD fYgmEwGTRX6xx5RqMDXVzoNhOmRbRqVxa/BSyIsIINT/Ww6PDNKdQSKTrZEg 6s5zelIyh/ZFGnmhVspgoJ8LZ5Q2FF7wL5ZjTbIr27JYyZ5Qu1opSg4sDVRC eG1Zp+IV0VOdAEGkhOgIVrPDnRKDG7Wos8ZvA6JtajmOabinyMtytBbPyD+E HMlekFqGVDTAymygZs08ZY1LVuFKDgNnrM6Sv9W2OUBehPBDOXqL72PJ0NQ4 e0O6EEGL8ALr2y4rDJ1XI/jILJEkJlSkHF6wGCvyCa0b5VDlGcRjO2E6LpLQ S2KdlJSq8XVZ9piPnM7zrHVt0to2+AtoL0+CQ0ON7GMNzeZz3ixJJqCzWAK4 FmkuTi9beA8mFnIuuV+MXd7KXtpCyaAhoV5fJ5HViDGNqJmyXmFdmkcPKxZn ZwWYfRzsAsCpH4bt2Vp9ChwgvNmeVC9Ua6ng1tJ4gqLPxgKLllUzLLUlO6AZ 4LR/q03qDZLfRIWbeGVZUGArxMhvDLyRzF4K2SnChHe+gcj9M/2TKJV9ASLW 10/O3j97rB/pPkWK+K4fPQYsHffrVJNWJdjm2ITG9XmgeKuHg3bGqa7JurXj vumMPGpGnhKUKaxpZNVAqT/R9hP1I/33WBWw64/0rdK6AfFPj8NfPz5Wd3wQ dursBzPi1Z1X9+yDgSs+bR1nUEEz2zNvskMHUZeBorj9KqS7wTsUdLDC0Jc2 Y66O2wiHoytO51wSztd65gGbiZRcEs7BoYIxcCSRMkCLCMNaskUpOU8tLsYS s5CBXpGPVgg52KIJNFAjBN4iTSJmNmfmVtB0OIqwaWkb4moGkTVFnlnSHesh i21ZJpcZVoiTBdl4GM7UzG1aOlZT9KRIWjH2643VDPSZOWNuxafw2+rdbRn3 vC32F4SR+mV/7E+0+8r56f26BDiToT4Uk3MEQyAwDZzPyYpb/9jOUm7W8VCf yKwvgllQqftCmh216lQrK5Z8gYQU4XVRp85p9tocNhuRnLOA3nTrvIZhUPw6 Y0z6N4Fr0OJ5nZrIujDDdrW386ucSd6rjt3mTh3reZ2kldNBXcO9RwF3FeP4 M8rXOXvCkmJN/ZpijrHJ0pTbStLtKPO6IBHANBPW14KePBo+KmNDPAa/6R6N H8SVorNDoAgd3b1wDDVnkU9i/f3F89GDjvozpGN6izzvSeh8jxTM3BT834/q njoFfITuTVnZFUIduBeQQHsD5x4Q/YWsrbgVukQU6khjyqmau8X/kvGq8vHx L1mvq7aw8bbW2iUijg0aBd78J1UYTb27U+CKeAtlHCmTJ2dmjmHDnZwJd9gO Z80YRzO1x7AG8GgLwRdOd7uCyp0hTirGqs9BYBvSEYMnOVtfJ3YILAWeABCv lZWjgA9dgiDTiZRHCpTFbD4beq9sSVaRbbJCLkd2CeBmA8uZ2DYAWyOlwI5+ AApSQo6fM+ILtuYQwO/ev3k9HuzXOeIFPvUe8l4VtKORXkGtj5jdtnUOznZt iiQnu0fBd9pmCJvkorLkHcTw/yTLSAziHoyQgLm7GwzZQXRariTCL8gALjlM HiLTlVpTVooJBUM1Vm+gHIeIaQBMma/AeTiSR4cIQ14XkeXUexP7OcDJb82Q 9Vsh1gUVzDyhVxsmYsPEFGtwGNYKa04i/MipCpc+6vfoYU/SV1wjqcxlOaJn A1XsHV58crzq/KaZUAby7fC+KSL65ZZ0v+i/9OOnLC3nP+vff5hMRl8hsY/f 9Pz3Hx4cjhYLfZ++TOgLaZOO1AOCbalvY6eO/Hs5346DfECGAIPsXXLljcaQ uD+ya8fCUKmKZLqWkOYTgRiHCqAj0hI0kOKi+wKPje8TayBkUtWOMq/MFaGX rVkbyulFUpArW9ShUmJ6dlQ2BRLk2Cakm2ERiQGbgSMZ8Xn636NnKiRSSKK9 BPqfk8cB4anUiK1XLdPA9MiBQQ4Qy6NhLVlf5z9tB+ykuqxzDgLKw3CowzE9 kWyY18olYlUECGaF2hWW5EzWKqdn89RkV7Q6UUH3m4w2aj4kvRwOyLuItJ+h qK0gb8rnxF26zjuWspTTrQivj8Z0zlV+7U4egTOYr9rM+ac2EY1oTbRkUGhN ijWBHNmkH4LNyUSEOqs1xSgeAI7WneqW41BU1EcKIx98elsOmxjhgizoQ7ET WANRMx+5O59G8zltTEzXh7xxVtnJGPseZGCKKqrZrOleIK2m6omnQ5CSFl0h vZDPr1kxN6vE7M/BV0JKaG6RZ1sSe2SKixzYAqlDFy3gzEl2nZNQ19kaStiA WCtDUSLsy5uIzuGCh2En6yKoJGjpJwQQrktSujTAWJKvpIHZqY2Wib2WIF6c aMZao2AkBZMJUbzXpez4kiLNWc/p0WJZzkC5Wbos5UmvN/MpxciIRagL3tAF DLGSlZ2+mnqj0eQV3GJwjfrBPoPZUE43w6YKGT+noohmz0JLp7bydK+QL3nx 7OI5cqZVHuWNYy6RFbv3LmnhzFVShPYelkmxDQ1Tlp2MYRg7xLZMCh8z+I06 rowkpFzVY74hQ71O841IWVJWTWGwMeBNLmK3JjhWPxA+4dH5xzK3pICTWNZv MxTB5Vc3eZ3GRPSaU2DOBYCrXFEMWqK7IPaBW2Ev2UOzH6AzJFBLFk30QQyE Cgu9oOMi3pJkcInQWxwLBtj7BRCHG+N0iFtatUuXXHCTuVPwpcTc0Iza1VF3 DKHIXhsl+FPNgG/mTfZSaAdCvUv0EVtWwy1nVjlHnsmEAD9zaNwNzwBiAX/p mj0a1s60dVmzSwrmLvO0Zm+MUwFS/CDVft/lskUAuVDVcoh4ymQUbYboMEji c+giKX4dcGRYyEG/BLtbZWRArmYdTvDR0VbWcD4jQTdAN3fs66GI43fSrVPd KVyzeGmaQmoMdNkGmjPFQigMb8a1Q9g0bUHrZK+PZ65cV1hno9zxGhS0AaLW TxAw7lYGvIKDVywobjKuC20T2BXvyGsWxdO2zpCU4TwPNiY2YSpzsp/ekKGJ yQ1bi52JfY/HAXiyMwi+5kK8ZT59uX16Os8OAvyCswEwcdENzNwQH8h3lM+4 4cO2EJ6S0gEM8NqIh2GjGhsSSn4EPwRZvZ7PkvfEyWu04sAzHJtUkgNnYQp4 ey5xgQPvAitBCHI8ErD7LXpDYiWoaVnooy1yZM61WFo3FoD3mspWLM5HkM3n lJcP3U91mX8SDMc8klahWXT4yMaig9aJ9dSSfRmNWDprwRUucJleD4jXvJwL 9HAwJby/yLqRAqISziGPFZShiuTi3VMnuGwo/EOYJr0ToTL+CRHshfSxKxwe zu0RLeEusJKsMwnBUpwKmw5cQQBhheF8shbbJMrR5aUaHyFxHSNSQtPECLL9 qBMouPIen3JDoeKHpmTJWZ+gRAlWPmPYo7qs8pUpNo3aGYYLEAVEXCtC9EL3 URlvX9MqjmslsMfQ3wyEJVPzwZUzuUzYsDmQubBO3hDKCX6nHIT4xi19/u7l c44gJmf6AB9Px5MzjAAp32QSRHtB8iXa2PXd7NqTTr7R4bBJ5ZJZTZqQPsyW lJVZY/myRt221E9f/PHFBaP47OXbb8+AxD7XkkUfkRERcLiYC4UTh2F/kKKE t+5VfEPjXRH5r3/5VyhONoRwLnNyTZGAgB+7Yp+DMBB6SueQVD49rZez/mWI yJf1qmvlTyteKBSNOGNOHhtUzjcBJwZwcsBygPhi0/jtixbIMEvhzp2UCNBQ lRKzXjbqF9bde6vOEcp2M22SQ/HOLpoYxPtx3Qvf0PmPj4/RQwFLIpLL+o3R 7FKl50/evNNIPHRr0Zj84OHJcVMZdw8e+rBYnTJ2uAOJxqkLc3k4mZwQb/72 yzG+SROOtOgs6jQdoVt00J32ENMmMmcSTsDYEVqcKNhoJnNG0/9wSdNiEeGM qpmAQc2PrUG0uWNLeJpJdAUkcOqP6BKxQiLWlqKaixGcFA69aofRPdXQwJ1i bRBDtGqH6DinkK61BeC5EUydchC5RI8cF0fboIdF0+MTlqnm3YpkYCl1sEf6 SORNn+rJ4ejwqB0Uk2e7d9DRgyF/POSP44l8HHJFCmlw9enOLq6o8fYHAA4j gdkROfzFvs0mo6PjZtAqyerK7hskrbA8qLSEtXjvIICNsfzx5aSBF8ZkTSSJ Pgc4S3m404LCdNmpN+7pw/sNmnlAVq+IsFChKEb2/tAjHdsb9QbBkXvTXni2 ZqqfJ2v/GTO7SyoMdZlM4VQe+smV29+CoP1H/Sk82M8Y04qLp06Xu+g8IU+1 P4l7mvkePp7fATo4rGo4rzO8BaB30WuXU/dcJL2IoJXJQhdWqfCXlwbHArpZ kezc8WRE4kJcMWLGOdXSx56wswUdKzm0JoXGWmQ7xdlGudA/LICiMDlScJEe K0RSSyUn06Snr+2+4c6cFdIA4g5cJdJWwO6YaHeSfvJn2FD4ptHGVKpu55Sh CCInXs5cNm8q63B7QJLx9zF3XBRmncSknuw1ObRS7bhOijxjF9g15MDhyknR sy2kGD5yrhRauBS3cJVBHxj7o7vBPKd+YHGJB1khkqGy2RKV4Vi5bgt3ycD1 O0qmDjkkieolsEQRhWNz4Nao7h7Skub7k9Da6uEKmkmIc7id0rdVVrlyZciN q7F0Giwl9evGwmYTEARZhFQ0B4BEABV0XpHRTJEyK65cTLDiKg6NakqgTY+z j/BMxnUXW3bKmui5uQpK4XDsPSBS8XIuQ1D4FMqkpkKJ/SYhD8mnDQQHLlA6 46YewZfjMA5ymw5qbS5RkXLJ9l1K4nxKqud+QumSbabFrMul+ON5gNV26uEV hLR5mHoZAIz3iLcSc5nlYDyU99Z1pVfoXvRlM9VFge5v9TYOJCYNMTds3HbB tep3+ye3ppB2MUlKuP2WYrVrbkvJJPnS9K01VFuSLEJaVpBLmdjutoVHPsWN kTLB0vMaTq0YdRwHpskqAepkLRfGF/m6gIoimF40jiX4civ1Uy696BBtTVGY jcvjtPWMJo60PikfYkr1pV2cl2EH9wad8XPxdSA1RbjhIDirGJfd5d1B+p4x TZYHiYuB1MvStMY9jcq7jVC9gGvEh/C+olRQFoRuaaqB0pyiKk1Gcm4+tl3V /Z9Q6x21YoqmYxpBMt/7eaDuFOY80uPxWGEef9OnrvP9A4FWLxatdsnuSfAR xBrOTZOzdQxGC7U3G29ZS0tO1EUXDidMGg80zERw8JVZk8+MajB0DPcEONLK xt0eHoodON7GimpNvikHxmGH6Nxu4B3NQGV39SMvLk2WfGTunDmKQdBJQ88W dQEqjWThFpOzsXrWLipxGSH8KkPVOrxSIK2sLZj066ZIKoSIEgkp15/rI5PZ 7363vVk5C4XQ6fH2rWoMRWztiteRbEaducYzC50YR6aIPWy26d5DKw+qd5yk Hbu4KUCY4LtCaX3e1VYcQbmWXcI9qeuCU2GqVbIrrigGrbuBXRcTLak67u/R fYByZTcDZaJKpITDaFmFFBPSql3t1JSjd5SmEqVJEvPSSnUbKfVAfLcNnmAR eVWnwZ2KF/IqANFcxcmC2Q32hWc40bskL2RUGo4unQsiRk0FAAS4YN2GKJL1 J1NNjP64gX6fjU6I1ed0Kph9b3rRvAAwjatQmnToGKRAMbgg/VtKodenG3yx yJOh5ySiFInoMSbQX5EvVK8rLXh3nXCxIFRNwsBOO33jbrC5fPc3OlyhebyH 6+npfXf3pNFovU8JZI8bEXH7j/THnsX0wQGFIN/oeZrnMTetydaDXa0FLnQ6 6xV9dWtIW8Ov6iqknhtl5fW7TzNIw1HgBYX9/ooLSJ2dQnwaSZfyBiWh1VVr DyTnRkofAndAj9N0K6w50D/dd8N/lh+Y4r5i2s87E/qorrUID/cO0b2LNz6D Q9zFznl2MXfmspwAHs4Ve9rILHPKSYxpFdwEKp1uhk44DRuPRTtxLbFBanMH U/JDXMEv8giShTysLX2LlGrFcKyQ8ROFx9c2UKF1xb5GpYnstC0YjJ+m3YqH 5c5PVpEt4Kq1B4C9Kexf0Q/L3FHqvoQ3BzGJG5fcOq6s1wtKgJLLgc7z9BUn jgi4VemAY62SEO2aqD7tT6DTCPcZke8S+X9vs1cvcd+Bb6kiT1V2eq/amyuK t2VycocftuaTYfuQbXnJ0TvyiIqYlcEpuxrQAdeQVuFL9/RO0TP93fnXvWvy Uo4eK/r63fAcbczfBez4VxJrJAPOg2do9unt8qM/Y9v0wUERDtu82mHKF6hj rqRZ2HVREW8lLjvVoVWrtWHJkY/HlMzeKM6BcXVKcAs+bwjr7j1GdVFIa450 EUgdNac9iKCRVavamUD7ISIqouvbWZ8gUCxb6+NuBvh7O45sCHfPXp+hdQ0e vvR47rn88shd5Gou3TghKfniM+Aq7CUZDtvcj63cnQriKlzCI3SaEU1Cu3VT 3JY5xUb1bm87F97b2h7fKd29YD/4urlwfXfXk/xz8GT7SuY7nwnfvnL507vn 58DHz9tXKrdetFcmt160VyL3vJjve9FeaQxf+MuKDZ5+/cqi8J7HuY2ZNUHQ VZP1fk+f9T5Sgpq3U9cAk2TFInrUw8V/rPH1b0Yjvq7+8ORIj0aPSQujTFAQ nyXd5f1tmd0+tcaCgXHR+qLMNbliLBIuIGgV+9ZNOX+1ly/KuTv2MJlJ5i5v 4OVk/GB8eCiNAE47o3/FFJICJoeHM+4e0a1VYC3UmABnQRROIlGqq0u3+iuI +2Q7sdmfvpy2/1ocXH8YDNXgUPxAJLKCMx0dMoD89Uvdj/OaUMbht/UXsrjl Irjqf49w5v5cAKFpKbXjPLvM2dXbQzHIMP/5B6li0E93vpG/z+z7Cb3n3NQx 274j32rS//ozf13gYE0ux8FXDx8DbqJtXcDSR59TNsGl83L/JJF4f/cOFXw4 RD9wkomNzq/cNUTRwRfLmuWRzSvqdKPIw5U2KRfBkhZO7bXLRriGxrXcl2y0 oSQYRP0quWrmGHstDoaNlnwVjHsV4I2zMyKpw8VGnHRkThASlsIqTA658Wy2 m1Kati5vVJpjEHMTz6y4b6FLfnEuRP628oNSVB2rM2fvpIWHH7rSdJsw+Wsd U2ie1yVSFNI44S4IX+O2qvK5AfTt9aK6suR4h38toQzWMtd5wkEl/1WCuYmu iLkjxMipjS+l32CHO6C6xDGw8aNelkNrfZes9PtoaQgZZX2Jq1VEP9+uQ2gg iZfVxtupRq8jbvha57VNSaRj3y5vUDOMaumFYMx8a7Mr/SQpriiA+zhWb02d 6r/ffEyuiZWWNsXcpMxTU/mrA87/EuGlg7Ih4dxfm1HH6nuaDIUrnrrxckvY ZZ8YNvlrJvriH/FHVUiXZm1XpI4K65w6nnT48MsJ7huydtcvcwrPf8D19akO hNp31ynW+/8N6g7e9e1GAAA= --></rfc>