rfc9165.original.xml   rfc9165.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 --> -ietf-cbor-cddl-control-07" number="9165" obsoletes="" updates="" submissionType
<?rfc toc="yes"?> ="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs
<?rfc sortrefs="yes"?> ="true" symRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc compact="yes"?> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<?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" obsoletes="" updates
="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRef
s="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <front>
<title abbrev="CDDL control operators">Additional Control Operators for CDDL <title abbrev="CDDL Control Operators">Additional Control Operators for the
</title> Concise Data Definition Language (CDDL)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-cddl-control-07"/> <seriesInfo name="RFC" value="9165"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2021" month="October" day="22"/> <date year="2021" month="December"/>
<keyword>Internet-Draft</keyword>
<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> <abstract>
<t>The Concise Data Definition Language (CDDL), standardized in RFC 8610, <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610,
provides "control operators" as its main language extension point.</t> provides "control operators" as its main language extension point.</t>
<t>The present document defines a number of control operators that were <t>The present document defines a number of control operators that were
not yet ready at the time RFC 8610 was completed: not yet ready at the time RFC 8610 was completed:
<tt>.plus</tt>, <tt>.cat</tt> and <tt>.det</tt> for the construction of constant <tt>.plus</tt>, <tt>.cat</tt>, and <tt>.det</tt> for the construction of constan
s, ts;
<tt>.abnf</tt>/<tt>.abnfb</tt> for including ABNF (RFC 5234/RFC 7405) in CDDL sp <tt>.abnf</tt>/<tt>.abnfb</tt> for including ABNF (RFC 5234 and RFC 7405) in CDD
ecifications, and L specifications; and
<tt>.feature</tt> for indicating the use of a non-basic feature in an instance.< /t> <tt>.feature</tt> for indicating the use of a non-basic feature in an instance.< /t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Concise Data Definition Language (CDDL), standardized in <xref targ et="RFC8610" format="default"/>, <t>The Concise Data Definition Language (CDDL), standardized in <xref targ et="RFC8610" format="default"/>,
provides "control operators" as its main language extension point provides "control operators" as its main language extension point
(<xref section="3.8" sectionFormat="of" target="RFC8610" format="default"/>).</t > (<xref section="3.8" sectionFormat="of" target="RFC8610" format="default"/>).</t >
<t>The present document defines a number of control operators that were <t>The present document defines a number of control operators that were
not yet ready at the time RFC 8610 was completed:</t> not yet ready at the time <xref target="RFC8610"/> was completed:</t>
<table anchor="tbl-new" align="center"> <table anchor="tbl-new" align="center">
<name>New control operators in this document</name> <name>New Control Operators in this Document</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Purpose</th> <th align="left">Purpose</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">.plus</td> <td align="left">.plus</td>
<td align="left">Numeric addition</td> <td align="left">Numeric addition</td>
</tr> </tr>
<tr> <tr>
<td align="left">.cat</td> <td align="left">.cat</td>
<td align="left">String Concatenation</td> <td align="left">String concatenation</td>
</tr> </tr>
<tr> <tr>
<td align="left">.det</td> <td align="left">.det</td>
<td align="left">String Concatenation, pre-dedenting</td> <td align="left">String concatenation, pre-dedenting</td>
</tr> </tr>
<tr> <tr>
<td align="left">.abnf</td> <td align="left">.abnf</td>
<td align="left">ABNF in CDDL (text strings)</td> <td align="left">ABNF in CDDL (text strings)</td>
</tr> </tr>
<tr> <tr>
<td align="left">.abnfb</td> <td align="left">.abnfb</td>
<td align="left">ABNF in CDDL (byte strings)</td> <td align="left">ABNF in CDDL (byte strings)</td>
</tr> </tr>
<tr> <tr>
<td align="left">.feature</td> <td align="left">.feature</td>
<td align="left">Indicate name of feature used (extension point)</td > <td align="left">Indicates name of feature used (extension point)</t d>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target= NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"RFC8174" format="default"/> when, and only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This specification uses terminology from <xref target="RFC8610" forma t="default"/>. <t>This specification uses terminology from <xref target="RFC8610" forma t="default"/>.
In particular, with respect to control operators, "target" refers to In particular, with respect to control operators, "target" refers to
the left-hand side operand, and "controller" to the right-hand side operand. the left-hand side operand and "controller" to the right-hand side operand.
"Tool" refers to tools along the lines of that described in <xref section="F" se ctionFormat="of" target="RFC8610" format="default"/>. "Tool" refers to tools along the lines of that described in <xref section="F" se ctionFormat="of" target="RFC8610" format="default"/>.
Note also that the data model underlying CDDL provides for text Note also that the data model underlying CDDL provides for text
strings as well as byte strings as two separate types, which are strings as well as byte strings as two separate types, which are
then collectively referred to as "strings".</t> then collectively referred to as "strings".</t>
<t>The term ABNF in this specification stands for the combination of <t>The term "ABNF" in this specification stands for the combination of
<xref target="RFC5234" format="default"/> and <xref target="RFC7405" format="def <xref target="RFC5234" format="default"/> and <xref target="RFC7405" format="def
ault"/>, i.e., the ABNF control operators defined by ault"/>; i.e., the ABNF control operators defined by
this document allow use of the case-sensitive extensions defined in this document allow use of the case-sensitive extensions defined in
<xref target="RFC7405" format="default"/>.</t> <xref target="RFC7405" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="computed-literals" numbered="true" toc="default"> <section anchor="computed-literals" numbered="true" toc="default">
<name>Computed Literals</name> <name>Computed Literals</name>
<t>CDDL as defined in <xref target="RFC8610" format="default"/> does not h ave any mechanisms to compute <t>CDDL as defined in <xref target="RFC8610" format="default"/> does not h ave any mechanisms to compute
literals. To cover a large part of the use cases, this specification adds three control 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 operators: <tt>.plus</tt> for numeric addition, <tt>.cat</tt> for string
concatenation, and <tt>.det</tt> for string concatenation with dedenting of concatenation, and <tt>.det</tt> for string concatenation with dedenting of
both sides (target and controller).</t> both sides (target and controller).</t>
<t>For these operators, as with all control operators, targets and <t>For these operators, as with all control operators, targets and
controllers are types. The resulting type is therefore formally a controllers are types. The resulting type is therefore formally a
function of the elements of the cross-product of the two types. 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 Not all tools may be able to work with non-unique targets or
controllers.</t> controllers.</t>
<section anchor="numeric-addition" numbered="true" toc="default"> <section anchor="numeric-addition" numbered="true" toc="default">
<name>Numeric Addition</name> <name>Numeric Addition</name>
<t>In many cases in a specification, numbers are needed relative to a <t>In many cases, numbers are needed relative to a
base number. The <tt>.plus</tt> control identifies a number that is base number in a specification. The <tt>.plus</tt> control identifies a number
constructed by adding the numeric values of the target and of the that is
constructed by adding the numeric values of the target and the
controller.</t> controller.</t>
<t>Target and controller MUST be numeric. <t>The target and controller both <bcp14>MUST</bcp14> be numeric.
If the target is a floating point number and the controller an integer 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 number, or vice versa, the sum is converted into the type of the
target; converting from a floating point number to an integer selects target; converting from a floating point number to an integer selects
its floor (the largest integer less than or equal to the floating its floor (the largest integer less than or equal to the floating
point number, i.e., rounding towards negative infinity).</t> point number, i.e., rounding towards negative infinity).</t>
<figure anchor="exa-plus"> <figure anchor="exa-plus">
<name>Example: addition to a base value</name> <name>An Example of Addition to a Base Value</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
interval<BASE> = ( interval<BASE> = (
BASE => int ; lower bound BASE => int ; lower bound
(BASE .plus 1) => int ; upper bound (BASE .plus 1) => int ; upper bound
? (BASE .plus 2) => int ; tolerance ? (BASE .plus 2) => int ; tolerance
) )
X = 0 X = 0
Y = 3 Y = 3
rect = { rect = {
interval<X> interval<X>
interval<Y> interval<Y>
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The example in <xref target="exa-plus" format="default"/> contains th e generic definition of a CDDL <t>The example in <xref target="exa-plus" format="default"/> contains th e generic definition of a CDDL
group <tt>interval</tt> that gives a lower and an upper bound and optionally group <tt>interval</tt> that gives a lower and upper bound and, optionally,
a tolerance. a tolerance.
The parameter BASE allows the non-conflicting use of multiple of these The parameter BASE allows the non-conflicting use of a multiple of these
interval groups in one map, by assigning different labels to the interval groups in one map by assigning different labels to the
entries of the interval. entries of the interval.
<tt>rect</tt> combines two of these interval groups into a map, one group for The rule <tt>rect</tt> combines two of these interval groups into a map, one gro
the X dimension (using 0, 1, and 2 as labels) and one for Y dimension up 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> (using 3, 4, and 5 as labels).</t>
</section> </section>
<section anchor="string-concatenation" numbered="true" toc="default"> <section anchor="string-concatenation" numbered="true" toc="default">
<name>String Concatenation</name> <name>String Concatenation</name>
<t>It is often useful to be able to compose string literals out of <t>It is often useful to be able to compose string literals out of
component literals defined in different places in the specification.</t> component literals defined in different places in the specification.</t>
<t>The <tt>.cat</tt> control identifies a string that is built from a <t>The <tt>.cat</tt> control identifies a string that is built from a
concatenation of the target and the controller. concatenation of the target and the controller.
Target and controller MUST be strings. The target and controller both <bcp14>MUST</bcp14> be strings.
The result of the operation has the type of the target. The result of the operation has the same type as the target.
The concatenation is performed on the bytes in both strings. The concatenation is performed on the bytes in both strings.
If the target is a text string, the result of that concatenation MUST If the target is a text string, the result of that concatenation <bcp14>MUST</bc p14>
be valid UTF-8.</t> be valid UTF-8.</t>
<figure anchor="exa-cat"> <figure anchor="exa-cat">
<name>Example: concatenation of text and byte string</name> <name>An Example of Concatenation of Text and Byte Strings</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
a = "foo" .cat ' c = "foo" .cat '
bar bar
baz baz
' '
; on a system where the newline is \n, is the same string as: ; on a system where the newline is \n, is the same string as:
b = "foo\n bar\n baz\n" b = "foo\n bar\n baz\n"
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The example in <xref target="exa-cat" format="default"/> <t>The example in <xref target="exa-cat" format="default"/>
builds a text string named <tt>a</tt> out of concatenating the target text strin g <tt>"foo"</tt> builds a text string named <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. and the controller byte string entered in a text form byte string literal.
(This particular idiom is useful when the text string contains (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 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 read when entered in the format that the pure CDDL text string
notation inherits from JSON.)</t> notation inherits from JSON.)</t>
</section> </section>
<section anchor="string-concatenation-with-dedenting" numbered="true" toc= "default"> <section anchor="string-concatenation-with-dedenting" numbered="true" toc= "default">
<name>String Concatenation with Dedenting</name> <name>String Concatenation with Dedenting</name>
<t>Multi-line string literals for various applications, including <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 embedded ABNF (<xref target="embedded-abnf" format="default"/>), need to be set flush left, at least
partially. partially.
Often, having some indentation in the source code for the literal can Often, having some indentation in the source code for the literal can
promote readability, as in <xref target="exa-det" format="default"/>.</t> promote readability, as in <xref target="exa-det" format="default"/>.</t>
<figure anchor="exa-det"> <figure anchor="exa-det">
<name>Example: dedenting concatenation</name> <name>An Example of Dedenting Concatenation</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
oid = bytes .abnfb ("oid" .det cbor-tags-oid) oid = bytes .abnfb ("oid" .det cbor-tags-oid)
roid = bytes .abnfb ("roid" .det cbor-tags-oid) roid = bytes .abnfb ("roid" .det cbor-tags-oid)
cbor-tags-oid = ' cbor-tags-oid = '
oid = 1*arc oid = 1*arc
roid = *arc roid = *arc
arc = [nlsb] %x00-7f arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff nlsb = %x81-ff *%x80-ff
' '
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The control operator <tt>.det</tt> works like <tt>.cat</tt>, except t hat both <t>The control operator <tt>.det</tt> works like <tt>.cat</tt>, except t hat both
arguments (target and controller) are independently <em>dedented</em> before arguments (target and controller) are independently <em>dedented</em> before
the concatenation takes place.</t> the concatenation takes place.</t>
<t>For the first rule in <xref target="exa-det" format="default"/>, the result is <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> equivalent to <xref target="exa-det-result" format="default"/>.</t>
<figure anchor="exa-det-result"> <figure anchor="exa-det-result">
<name>Dedenting example: result of first .det</name> <name>Dedenting Example: Result of First .det</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
oid = bytes .abnfb 'oid oid = bytes .abnfb 'oid
oid = 1*arc oid = 1*arc
roid = *arc roid = *arc
arc = [nlsb] %x00-7f arc = [nlsb] %x00-7f
nlsb = %x81-ff *%x80-ff nlsb = %x81-ff *%x80-ff
' '
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>For the purposes of this specification, we define dedenting as:</t> <t>For the purposes of this specification, we define "dedenting" as:</t>
<ol spacing="normal" type="1"><li>determining the smallest amount of lef <ol spacing="normal" type="1"><li>determining the smallest amount of lef
t-most blank space (number of tmost blank space (number of
leading space characters) present in all the non-blank lines, and</li> leading space characters) present in all the non-blank lines, and</li>
<li>removing exactly that number of leading space characters from each <li>removing exactly that number of leading space characters from each
line. For blank (blank space only or empty) lines, there may be line. For blank (blank space only or empty) lines, there may be
less (or no) leading space characters than this amount, in which fewer (or no) leading space characters than this amount, in which
case all leading space is removed.</li> case all leading space is removed.</li>
</ol> </ol>
<t>(The name <tt>.det</tt> is a shortcut for "dedenting cat". <t>(The name <tt>.det</tt> is a shortcut for "dedenting cat".
The maybe more obvious name <tt>.dedcat</tt> has not been chosen The maybe more obvious name <tt>.dedcat</tt> has not been chosen
as it is longer and may invoke unpleasant images.)</t> as it is longer and may invoke unpleasant images.)</t>
<t>Occasionally, dedenting of only a single item is needed. <t>Occasionally, dedenting of only a single item is needed.
This can be achieved by using this operator with an empty string, 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 combine d e.g., <tt>"" .det rhs</tt> or <tt>lhs .det ""</tt>, which can in turn be combine d
with a <tt>.cat</tt>: in the construct <tt>lhs .cat ("" .det rhs)</tt>, only <tt >rhs</tt> with a <tt>.cat</tt>: in the construct <tt>lhs .cat ("" .det rhs)</tt>, only <tt >rhs</tt>
is dedented.</t> is dedented.</t>
skipping to change at line 254 skipping to change at line 261
<section anchor="embedded-abnf" numbered="true" toc="default"> <section anchor="embedded-abnf" numbered="true" toc="default">
<name>Embedded ABNF</name> <name>Embedded ABNF</name>
<t>Many IETF protocols define allowable values for their text strings in <t>Many IETF protocols define allowable values for their text strings in
ABNF <xref target="RFC5234" format="default"/> <xref target="RFC7405" format="de fault"/>. ABNF <xref target="RFC5234" format="default"/> <xref target="RFC7405" format="de fault"/>.
It is often desirable to define a text string type in CDDL by It is often desirable to define a text string type in CDDL by
employing existing ABNF embedded into the CDDL specification. employing existing ABNF embedded into the CDDL specification.
Without specific ABNF support in CDDL, that ABNF would usually need to Without specific ABNF support in CDDL, that ABNF would usually need to
be translated into a regular expression (if that is even possible).</t> be translated into a regular expression (if that is even possible).</t>
<t>ABNF is added to CDDL in the same way that regular <t>ABNF is added to CDDL in the same way that regular
expressions were added: by defining a <tt>.abnf</tt> control operator. expressions were added: by defining a <tt>.abnf</tt> control operator.
The target is usually <tt>text</tt> or some restriction on it, the controller The target is usually <tt>text</tt> or some restriction on it, and the controlle r
is the text of an ABNF specification.</t> is the text of an ABNF specification.</t>
<t>There are several small issues, with solutions given here:</t> <t>There are several small issues; the solutions are given here:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ABNF can be used to define byte sequences as well as UTF-8 text <li>ABNF can be used to define byte sequences as well as UTF-8 text
strings interpreted as Unicode scalar sequences. This means this strings interpreted as Unicode scalar sequences. This means this
specification defines two control operators: <tt>.abnfb</tt> for ABNF specification defines two control operators: <tt>.abnfb</tt> for ABNF
denoting byte sequences and <tt>.abnf</tt> for denoting sequences of denoting byte sequences and <tt>.abnf</tt> for denoting sequences of
Unicode scalar values (codepoint) represented as UTF-8 text strings. Unicode scalar values (code points) represented as UTF-8 text strings.
Both control operators can be applied to targets of either string Both control operators can be applied to targets of either string
type; the ABNF is applied to sequence of bytes in the string type; the ABNF is applied to the sequence of bytes in the string
interpreting that as a sequence of bytes (<tt>.abnfb</tt>) or as a sequence and 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>). of code points represented as an UTF-8 text string (<tt>.abnf</tt>).
The controller string MUST be a text string.</li> The controller string <bcp14>MUST</bcp14> be a string. When a byte string , it <bcp14>MUST</bcp14> be valid UTF-8 and is interpreted as the text string th at has the same sequence of bytes.</li>
<li>ABNF defines a list of rules, not a single expression (called <li>ABNF defines a list of rules, not a single expression (called
"elements" in <xref target="RFC5234" format="default"/>). This is resolved by r equiring the "elements" in <xref target="RFC5234" format="default"/>). This is resolved by r equiring the
controller string to be one valid "element", followed by zero or controller string to be one valid "element", followed by zero or
more valid "rule" separated from the element by a newline; so the more valid "rules" separated from the element by a newline; thus, the
controller string can be built by preceding a piece controller string can be built by preceding a piece
of valid ABNF by an "element" that selects from that ABNF and a newline.</li> 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 <li>For the same reason, ABNF requires newlines; specifying newlines in
CDDL text strings is tedious (and leads to essentially unreadable CDDL text strings is tedious (and leads to essentially unreadable
ABNF). The workaround employs the <tt>.cat</tt> operator introduced in ABNF). The workaround employs the <tt>.cat</tt> operator introduced in
<xref target="string-concatenation" format="default"/> and the syntax for text i n byte strings. <xref target="string-concatenation" format="default"/> and the syntax for text i n byte strings.
As is customary for ABNF, the syntax of ABNF itself (NOT the syntax As is customary for ABNF, the syntax of ABNF itself (<em>not</em> the syntax
expressed in ABNF!) is relaxed to allow a single linefeed as a expressed in ABNF!) is relaxed to allow a single line feed as a
newline:</li> newline:</li>
</ul> </ul>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
CRLF = %x0A / %x0D.0A CRLF = %x0A / %x0D.0A
]]></sourcecode> ]]></sourcecode>
<ul spacing="normal"> <ul spacing="normal">
<li>One set of rules provided in an ABNF specification is often used in <li>One set of rules provided in an ABNF specification is often used in
multiple positions, in particular staples such as DIGIT and ALPHA. multiple positions, particularly staples such as DIGIT and ALPHA.
(Note that all rules referenced need to be defined in each ABNF (Note that all rules referenced need to be defined in each ABNF
operator controller string -- operator controller string --
there is no implicit import of <xref target="RFC5234" format="default"/> Core AB NF or other rules.) there is no implicit import of core ABNF rules from <xref target="RFC5234" forma t="default"/> or other rules.)
The composition this calls for can be provided by the <tt>.cat</tt> The composition this calls for can be provided by the <tt>.cat</tt>
operator, and/or by <tt>.det</tt> if there is indentation to be disposed of.</li > operator and/or by <tt>.det</tt> if there is indentation to be disposed of.</li>
</ul> </ul>
<t>These points are combined into an example in <xref target="exa-abnf" fo rmat="default"/>, which uses <t>These points are combined into an example in <xref target="exa-abnf" fo rmat="default"/>, which uses
ABNF from <xref target="RFC3339" format="default"/> to specify one each of the C ABNF from <xref target="RFC3339" format="default"/> to specify one of each of th
BOR tags defined in e Concise Binary Object Representation (CBOR) tags defined in
<xref target="RFC8943" format="default"/> and <xref target="RFC8949" format="def <xref target="RFC8943" format="default"/> and <xref target="RFC8949" forma
ault"/>.</t> t="default"/>.</t>
<figure anchor="exa-abnf"> <figure anchor="exa-abnf">
<name>Example: employing RFC 3339 ABNF for defining CBOR Tags</name> <name>An Example of Employing ABNF from RFC 3339 for Defining CBOR Tags<
<artwork name="" type="" align="left" alt=""><![CDATA[ /name>
<sourcecode type="cddl"><![CDATA[
; for RFC 8943 ; for RFC 8943
Tag1004 = #6.1004(text .abnf full-date) Tag1004 = #6.1004(text .abnf full-date)
; for RFC 8949 ; for RFC 8949
Tag0 = #6.0(text .abnf date-time) Tag0 = #6.0(text .abnf date-time)
full-date = "full-date" .cat rfc3339 full-date = "full-date" .cat rfc3339
date-time = "date-time" .cat rfc3339 date-time = "date-time" .cat rfc3339
; Note the trick of idiomatically starting with a newline, separating ; Note the trick of idiomatically starting with a newline, separating
; off the element in the concatenations above from the rule-list ; off the element in the concatenations above from the rule-list
skipping to change at line 335 skipping to change at line 343
full-date = date-fullyear "-" date-month "-" date-mday full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset full-time = partial-time time-offset
date-time = full-date "T" full-time date-time = full-date "T" full-time
' .det rfc5234-core ' .det rfc5234-core
rfc5234-core = ' rfc5234-core = '
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
; abbreviated here ; abbreviated here
' '
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="features" numbered="true" toc="default"> <section anchor="features" numbered="true" toc="default">
<name>Features</name> <name>Features</name>
<t>Commonly, the kind of validation enabled by languages such as <t>Commonly, the kind of validation enabled by languages such as
CDDL provides a Boolean result: valid, or invalid.</t> CDDL provides a Boolean result: valid or invalid.</t>
<t>In rapidly evolving environments, this is too simplistic. The data <t>In rapidly evolving environments, this is too simplistic. The data
models described by a CDDL specification may continually be enhanced models described by a CDDL specification may continually be enhanced
by additional features, and it would be useful even for a by additional features, and it would be useful even for a
specification that does not yet describe a specific future feature to specification that does not yet describe a specific future feature to
identify the extension point the feature can use, accepting such identify the extension point the feature can use and accept such
extensions while marking them as such.</t> extensions while marking them as extensions.</t>
<t>The <tt>.feature</tt> control annotates the target as making use of the <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. feature named by the controller. The latter will usually be a string.
A tool that validates an instance against that specification may mark A tool that validates an instance against that specification may mark
the instance as using a feature that is annotated by the the instance as using a feature that is annotated by the
specification.</t> specification.</t>
<t>More specifically, the tool's diagnostic output might contain <t>More specifically, the tool's diagnostic output might contain
the controller (right-hand side) as a feature name, and the target the controller (right-hand side) as a feature name and the target
(left-hand side) as a feature detail. However, in some cases, the target has (left-hand side) as a feature detail. However, in some cases, the target has
too much detail, and the specification might want to hint the tool too much detail, and the specification might want to hint to the tool
that more limited detail is appropriate. In this case, the controller that more limited detail is appropriate. In this case, the controller
should be an array, with the first element being the feature name should be an array, with the first element being the feature name
(that would otherwise be the entire controller), and the second (that would otherwise be the entire controller) and the second
element being the detail (usually another string), as illustrated in element being the detail (usually another string), as illustrated in
<xref target="exa-feat-array" format="default"/>.</t> <xref target="exa-feat-array" format="default"/>.</t>
<figure anchor="exa-feat-array"> <figure anchor="exa-feat-array">
<name>Providing explicit detail with .feature</name> <name>Providing Explicit Detail with .feature</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
foo = { foo = {
kind: bar / baz .feature (["foo-extensions", "bazify"]) kind: bar / baz .feature (["foo-extensions", "bazify"])
} }
bar = ... bar = ...
baz = ... ; complex stuff that doesn't all need to be in the detail baz = ... ; complex stuff that doesn't all need to be in the detail
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="exa-feat-map" format="default"/> shows what could be the definition of a person, with <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 potential extensions beyond <tt>name</tt> and <tt>organization</tt> being marked
<tt>further-person-extension</tt>. <tt>further-person-extension</tt>.
Extensions that are known at the time this definition is written can be Extensions that are known at the time this definition is written can be
collected into <tt>$$person-extensions</tt>. However, future extensions collected into <tt>$$person-extensions</tt>. However, future extensions
would be deemed invalid unless the wildcard at the end of the map is would be deemed invalid unless the wildcard at the end of the map is
added. added.
These extensions could then be specifically examined by a user or a These extensions could then be specifically examined by a user or a
tool that makes use of the validation result; the label (map key) tool that makes use of the validation result; the label (map key)
actually used makes a fine feature detail for the tool's diagnostic actually used makes a fine feature detail for the tool's diagnostic
output.</t> output.</t>
<t>Leaving out the entire extension point would mean that instances that <t>Leaving out the entire extension point would mean that instances that
make use of an extension would be marked as whole-sale invalid, making make use of an extension would be marked as wholesale invalid, making
the entire validation approach much less useful. the entire validation approach much less useful.
Leaving the extension point in, but not marking its use as special, Leaving the extension point in but not marking its use as special
would render mistakes such as using the label "<tt>organisation</tt>" instead of would render mistakes (such as using the label "<tt>organisation</tt>" instead o
"<tt>organization</tt>" invisible.</t> f
"<tt>organization</tt>") invisible.</t>
<figure anchor="exa-feat-map"> <figure anchor="exa-feat-map">
<name>Map extensibility with .feature</name> <name>Map Extensibility with .feature</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
person = { person = {
? name: text ? name: text
? organization: text ? organization: text
$$person-extensions $$person-extensions
* (text .feature "further-person-extension") => any * (text .feature "further-person-extension") => any
} }
$$person-extensions //= (? bloodgroup: text) $$person-extensions //= (? bloodgroup: text)
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="exa-feat-type" format="default"/> shows another example w here <tt>.feature</tt> provides for <t><xref target="exa-feat-type" format="default"/> shows another example w here <tt>.feature</tt> provides for
type extensibility.</t> type extensibility.</t>
<figure anchor="exa-feat-type"> <figure anchor="exa-feat-type">
<name>Type extensibility with .feature</name> <name>Type Extensibility with .feature</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
allowed-types = number / text / bool / null allowed-types = number / text / bool / null
/ [* number] / [* text] / [* bool] / [* number] / [* text] / [* bool]
/ (any .feature "allowed-type-extension") / (any .feature "allowed-type-extension")
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>A CDDL tool may simply report the set of features being used; the <t>A CDDL tool may simply report the set of features being used; the
control then only provides information to the process requesting the control then only provides information to the process requesting the
validation. validation.
One could also imagine a tool that takes arguments allowing the tool to accept One could also imagine a tool that takes arguments, allowing the tool to accept
certain features and reject others (enable/disable). The latter approach certain features and reject others (enable/disable). The latter approach
could for instance be used for a JSON/CBOR switch, as illustrated in could, for instance, be used for a JSON/CBOR switch, as illustrated in
<xref target="exa-feat-variants" format="default"/>, using SenML <xref target="R <xref target="exa-feat-variants" format="default"/>, using Sensor Measurement Li
FC8428" format="default"/> as the example data model sts (SenML) <xref target="RFC8428" format="default"/> as the example data model
used with both JSON and CBOR.</t> used with both JSON and CBOR.</t>
<figure anchor="exa-feat-variants"> <figure anchor="exa-feat-variants">
<name>Describing variants with .feature</name> <name>Describing Variants with .feature</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
SenML-Record = { SenML-Record = {
; ... ; ...
? v => number ? v => number
; ... ; ...
} }
v = JC<"v", 2> v = JC<"v", 2>
JC<J,C> = J .feature "json" / C .feature "cbor" JC<J,C> = J .feature "json" / C .feature "cbor"
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>It remains to be seen if the enable/disable approach can lead to new <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 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> mutually exclusive use of features, as would be needed in this example.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests IANA to register the contents of <t>IANA has registered the contents of
<xref target="tbl-iana-reqs" format="default"/> into the registry <xref target="tbl-iana-reqs" format="default"/> into the "CDDL Control Operators
"<xref section="CDDL Control Operators" relative="#cddl-control-operators" secti " registry of <xref target="IANA.cddl" format="default"/>:</t>
onFormat="bare" target="IANA.cddl" format="default"/>" of <xref target="IANA.cdd
l" format="default"/>:</t>
<table anchor="tbl-iana-reqs" align="center"> <table anchor="tbl-iana-reqs" align="center">
<name>New control operators to be registered</name> <name>New Control Operators</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">.plus</td> <td align="left">.plus</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
<tr> <tr>
<td align="left">.cat</td> <td align="left">.cat</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
<tr> <tr>
<td align="left">.det</td> <td align="left">.det</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
<tr> <tr>
<td align="left">.abnf</td> <td align="left">.abnf</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
<tr> <tr>
<td align="left">.abnfb</td> <td align="left">.abnfb</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
<tr> <tr>
<td align="left">.feature</td> <td align="left">.feature</td>
<td align="left">[RFCthis]</td> <td align="left">RFC 9165</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section removeInRFC="true" anchor="implementation-status" numbered="true" t
oc="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" tar
get="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 targe
t="https://github.com/anweiss/cddl/pull/79">https://github.com/anweiss/cddl/pull
/79</eref>).</t>
</section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security considerations</name> <name>Security Considerations</name>
<t>The security considerations of <xref target="RFC8610" format="default"/ > apply.</t> <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 <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 believed to be irrelevant to the respective document, the use of
formal description techniques cannot only simplify, but sometimes also formal description techniques cannot only simplify but sometimes also
complicate a specification. complicate a specification.
This can lead to security problems in implementations and in the This can lead to security problems in implementations and in the
specification itself. specification itself.
As with CDDL itself, ABNF should be judiciously applied, and overly As with CDDL itself, ABNF should be judiciously applied, and overly
complex (or "cute") constructions should be avoided.</t> complex (or "cute") constructions should be avoided.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
<front> xml"/>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz">
<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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="IANA.cddl" target="https://www.iana.org/assignments/c ddl"> <reference anchor="IANA.cddl" target="https://www.iana.org/assignments/c ddl">
<front> <front>
<title>Concise Data Definition Language (CDDL)</title> <title>Concise Data Definition Language (CDDL)</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
<front> xml"/>
<title>Augmented BNF for Syntax Specifications: ABNF</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.
<author fullname="D. Crocker" initials="D." role="editor" surname="C xml"/>
rocker"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<author fullname="P. Overell" initials="P." surname="Overell"> xml"/>
<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 A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [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/rfc7
405">
<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 Ba
ckus-Naur Form) to include a way to specify US-ASCII string literals that are ma
tched 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/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8
428"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.
<front> xml"/>
<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 sen
sor measurements and device parameters in Sensor Measurement Lists (SenML). Rep
resentations are defined in JavaScript Object Notation (JSON), Concise Binary Ob
ject Representation (CBOR), Extensible Markup Language (XML), and Efficient XML
Interchange (EXI), which share the common SenML data model. A simple sensor, su
ch 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 measure
ments of the sensor or to be configured.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8428"/>
<seriesInfo name="DOI" value="10.17487/RFC8428"/>
</reference>
<reference anchor="CDDL-RS" target="https://github.com/anweiss/cddl"> <reference anchor="CDDL-RS" target="https://github.com/anweiss/cddl">
<front> <front>
<title>cddl-rs</title> <title>cddl-rs</title>
<author initials="A." surname="Weiss" fullname="Andrew Weiss"> <author initials="A." surname="Weiss" fullname="Andrew Weiss">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date/>
</front>
</reference>
<reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3
339">
<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 Interne
t protocols that is a profile of the ISO 8601 standard for representation of dat
es 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/rfc8
943">
<front>
<title>Concise Binary Object Representation (CBOR) Tags for Date</ti
tle>
<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 i
n RFC 7049, is a data format whose design goals include the possibility of extre
mely small code size, fairly small message size, and extensibility without the n
eed for version negotiation. </t>
<t>In CBOR, one point of extensibility is the definition of CBOR t
ags. 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 requi
rements 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 da
ys since the date 1970-01-01 in the Gregorian calendar for applications needing
a numeric date representation without a time. This specification is the referenc
e 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/rfc8
949">
<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 forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front> </front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference> </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>
</references> </references>
<section numbered="false" anchor="acknowledgements" toc="default"> <section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Jim Schaad suggested several improvements. <t><contact fullname="Jim Schaad"/> suggested several improvements.
The <tt>.feature</tt> feature was developed out of a discussion with Henk Birkho The <tt>.feature</tt> feature was developed out of a discussion with <contact fu
lz. llname="Henk Birkholz"/>.
Paul Kyzivat helped isolate the need for <tt>.det</tt>.</t> <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 <t>.det is an abbreviation for "dedenting cat", but Det is also the name
of a German TV Cartoon character created in the 1960s.</t> of a German TV cartoon character created in the 1960s.</t>
<!-- LocalWords: dedenting dedented
-->
</section> </section>
</back> </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> </rfc>
 End of changes. 74 change blocks. 
525 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/