One document matched: draft-vanderstok-core-cbor-yid-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC7159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY I-D.ietf-core-yang-cbor SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-yang-cbor.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-netconf-yang-patch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-patch.xml">
<!ENTITY I-D.vanderstok-core-comi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vanderstok-core-comi.xml">
<!ENTITY I-D.bierman-core-yid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bierman-core-yid.xml">
<!ENTITY I-D.bormann-appsawg-cbor-merge-patch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-appsawg-cbor-merge-patch.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-vanderstok-core-cbor-yid-00">
<front>
<title abbrev="CBOR YIDs">CBOR format for YIDs</title>
<author initials="P." surname="van der Stok" fullname="Peter van der Stok">
<organization abbrev="consultant">consultant</organization>
<address>
<phone>+31-492474673 (Netherlands), +33-966015248 (France)</phone>
<email>consultancy@vanderstok.org</email>
<uri>www.vanderstok.org</uri>
</address>
</author>
<author initials="A" surname="Bierman" fullname='Andy Bierman' >
<organization>YumaWorks, Inc.</organization>
<address>
<postal>
<street>685 Cochran St.</street>
<street>Suite #160</street>
<city>Simi Valley</city>
<region>CA</region>
<code>93065</code>
<country>USA</country>
</postal>
<email>andy@yumaworks.com</email>
</address>
</author>
<date />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
This document describes CoAP content formats to transport CBOR
encoded YANG objects which use numeric YANG object identifiers. YANG
objects are serialized according to the YANG to CBOR encoding. The
object identifier is composed of a module number followed by a yang
name numeric identifier
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested,
and should be sent to core@ietf.org.
</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>
The Concise Binary Object Representation (CBOR, <xref target="RFC7049"/>) defines a
binary representation for data that can be described using an
extension of the JSON data model <xref target="RFC7159"/>.
</t><t>
Numeric YANG Identifiers (YID), described in <xref target="I-D.bierman-core-yid"/>, represent YANG object names as numeric identifiers. They are structured according to a module_id, local_id pattern.
</t><t>
This document specifies two new content formats.
The content-format, called "application/cbor+yid", follows the YANG to CBOR encoding specified in <xref target="I-D.ietf-core-yang-cbor"/>, and the YANG name string to numeric identifier specified in <xref target="I-D.bierman-core-yid"/>.
</t><t>
The content format called "application/merge-patch+cbor+yid" is an extension of the format specified in <xref target="I-D.bormann-appsawg-cbor-merge-patch"/>
</t><t>
The delta encoding specified in <xref target="I-D.ietf-core-yang-cbor"/>, is used throughout.
</t><t>
The format is primarily intended to describe the numeric identifiers of the CBOR encoded YANG objects transported with CoAP <xref target="RFC7252"/> methods, as specified in <xref target="I-D.vanderstok-core-comi"/>.
</t>
<section anchor="terminology" title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119"/>.
</t>
<t>
Readers of this specification should be familiar with all the terms and concepts
discussed in <xref target="RFC2578"/>.
</t>
<t>
The following terms are defined in the NETCONF protocol <xref target="RFC6241"/>:
client, configuration data, datastore, and server.
</t>
<t>
The following terms are defined in the YANG data modelling language
<xref target="RFC6020"/>: container, data node, key, key leaf, leaf, leaf-list, and list.
</t>
<t>
The following terms are defined in RESTCONF protocol
<xref target="I-D.ietf-netconf-restconf"/>:
data resource, data-store resource, edit operation, query parameter,
target resource, and unified data-store.
</t>
<t>
The following terms are defined in YANG ID protocol
<xref target="I-D.bierman-core-yid"/>:
YANG module schema tree, YANG ID, YANG Anchor, YANG Anchor subtree, and YANG Identifier File.
</t>
<t>
The following terms are defined in this document:
<list style="hanging">
<t hangText="To be defined term:"> TODO: specification.
</t>
</list>
</t>
</section> <!-- Terminology -->
</section> <!-- Introduction -->
<section anchor="Design-Objectives" title="Design Objectives">
<t>
This work is motivated by the need to minimize the size of numeric object identifiers
within protocol messages representing YANG data, encoded according to the CBOR binary format. Both a single complete resource
description used with GET and PUT, and partial resource descriptions
used with FETCH, PATCH and iPATCH are specified.
</t>
</section> <!-- Design Objectives -->
<section title="YANG Identifier">
<t>
The numeric YANG identifier used in this document is specified in <xref target="I-D.bierman-core-yid"/>.
A YANG Identifier is constructed of 2 fields:
</t>
<figure>
<artwork align="left"><![CDATA[
YANG Identifier Format:
+-------------+ +------------+
| module_id | | local_id |
+-------------+ +------------+
]]></artwork>
</figure>
<t>
The meaning of the identifiers in the above figure is:
<list>
<t> module_id: This is a mandatory number that uniquely identifies a module with a size of "module-bits" bits.
</t>
<t> local_id: This is a number that uniquely defines a YANG name within a module with a size of "local-bits" bits. Local identifiers can be one of two formats: YANG Hash or Manually Assigned.</t>
</list>
</t>
<section anchor="YID-ID" title="YANG Identifier encoding">
<t>
A YANG Identifier (YID) is constructed from module_id and local_id according to the formula:
</t><t>
YID = (module_id*2^local-bits)+ local_id.
</t><t>
The CBOR encoding uses maps (major type 5) composed of pair (map.key, map.value). Maps can be the parent of children maps. A map can have 1 or zero parents. A map without parents is called a root.
</t><t>
Using delta encoding (see <xref target="I-D.ietf-core-yang-cbor"/>), the YID is encoded in the maps according to the following rules:
<list>
<t>If the map is a root, YID(root) = root.key.</t>
<t>If the map has a parent, YID(map) = map.key + YID(parent).</t>
</list>
</t>
</section> <!-- YANG identifier encoding -->
<section anchor="length" title="Length of CBOR major type 0 and 1">
<t>
Local_ids are represented as unsigned integers (major type 0) or negative integers (major type 1).
The two types in CBOR are either represented as one byte, or as multiple bytes, where the first byte indicates the length of the value. This has a consequence for the local_id value size. The smallest possible value is 23 (5 bits), encoded as one byte. For larger local_id values, their size should be 8, 16, 32, and 64 bits, encoded in CBOR by as many bits + 8 bits.
</t><t>
When the local_id is based on hashes, clashes can occur. Below two tables give the probability that at least one clash occurs or at least two clashes occur for a given hash size in bits and the number of names to be hashed.
</t>
<texttable anchor="CLASH-TAB" title="Probability of one or more clashes">
<ttcol align="left">Number of names</ttcol>
<ttcol align="left">5 bits</ttcol>
<ttcol align="left">8 bits</ttcol>
<ttcol align="left">16 bits</ttcol>
<ttcol align="left">32 bits</ttcol>
<c>5</c>
<c>3,1E-01</c><c>3,9E-02</c><c>1,5E-04</c><c>2,3E-09</c>
<c>10</c>
<c>1</c><c>1,7E-01 </c><c>6,9E-04</c><c>1,1E-08</c>
<c>20</c>
<c>1</c><c>7,4E-01</c><c>2,9E-03</c><c>4,4E-08</c>
<c>40</c>
<c>1</c><c>1</c><c>1,2E-02</c><c>1,8E-07</c>
<c>100</c>
<c>1</c><c>1</c><c>7,6E-02</c><c>1,2E-06</c>
<c>200</c>
<c>1</c><c>1</c><c>3,0E-01</c><c>4,6E-06</c>
</texttable>
<t>
</t>
<texttable anchor="SINGLE-CLASH" title="Probability of more than 2 entries equal clashes">
<ttcol align="left">Number of names</ttcol>
<ttcol align="left">5 bits</ttcol>
<ttcol align="left">8 bits</ttcol>
<ttcol align="left">16 bits</ttcol>
<ttcol align="left">32 bits</ttcol>
<c>5</c>
<c>5,9E-02</c><c>9,2E-04</c><c>1,4E-08</c><c>3,3E-18</c>
<c>10</c>
<c>1</c><c>2,5E-02</c><c>3,8E-07</c><c>8,8E-17</c>
<c>20</c>
<c>1</c><c>5,0E-01</c><c>7,6E-06</c><c>1,8E-15</c>
<c>40</c>
<c>1</c><c>1</c><c>1,4E-04</c><c>3,1E-14</c>
<c>100</c>
<c>1</c><c>1</c><c>5,6E-03</c><c>1,3E-12</c>
<c>200</c>
<c>1</c><c>1</c><c>9,1E-02</c><c>1,1E-10</c>
</texttable>
<t>
It is clear that for hash size of 5 bits, more than 5 names will certainly provoke one or more clashes. When the number of bits should be as small as possible, an assignment of numbers per hand is favored.
16 bit hashes can safely be used when less than 50 names are present in the module. 32 bit hashes are recommended when more than a few 1000 names occur in a module.
</t>
</section> <!-- CBOR length -->
</section> <!-- YANG Identifier -->
<section anchor="format" title="CBOR format to encode YID payload">
<t>
The general format in Diagnostic JSON is shown below:
</t>
<figure><artwork align="left">
<![CDATA[
[
{ module_id*2^module-bits: { key: value .... }},
{ module_id*2^module-bits: { key: value .... }},
...........................
]
]]></artwork></figure>
<t>
This represents an array of maps, where each map in the array represents a module.
When there is one module, the array is removed and a single map remains. The module value: module_id*2^module-bits helps to reduce the key value sizes when multiple root maps follow. When a single root map follows, the module value can be removed.
</t><t>
Two identifier forms are discussed in the two sections below:
</t>
<section anchor="mod_form" title="module form encoding">
<t>
The cbor-yid format is composed of an array (major type 4) of one or more maps (major type 5) called "module maps".
</t><t>
The array of module maps collapses to one module map when there is only one module map to transport. The module_id*2^module-bits is represented as an unsigned integer (major type 0).
</t><t>
The key is represented as an unsigned integer (major type 0) or negative integer (major type 1), where key = YID - module_id*2^module-bits. YID is the YANG identifier of the YANG object encoded with (key, value) pair.
</t>
</section> <!-- module form -->
<section anchor="loc_form" title="single root encoding">
<t>
In the special case that there is one module with one root,
the cbor-yid format is composed of one map (major type 5) called "object map" as shown below.
</t>
<figure><artwork align="left">
<![CDATA[
{ YID: value}
]]></artwork></figure>
<t>
YID is the YANG Identifier of the YANG root map encoded with the (YID, value) pair. YID = module_id*(2^module-bits) + local_id. The value of the map follows the standard CBOR to YANG encoding.
</t>
</section> <!-- single root form -->
</section> <!-- CBOR format -->
<section anchor="merge-patch" title="YID addition to merge-patch+cbor">
<t>
The general format in Diagnostic JSON is hown below:
</t>
<figure><artwork align="left">
<![CDATA[
[
{ module_id*2^module-bits: { merge-patch+cbor+yid format... }},
{ module_id*2^module-bits: { merge-patch+cbor+yid format --- }},
...........................
]
]]></artwork></figure>
<t>
The figure represents an array of module maps, where each module map in the array represents a module payload encoded in the content format application/merge-patch+cbor. When there is one module the array is removed and a single module remains.
</t><t>
The merge-patch+cbor+yid format follows the merge-patch+cbor encoding as specified in <xref target="I-D.bormann-appsawg-cbor-merge-patch"/> where each numeric YANG identifier is encoded with the map keys as described in <xref target="YID-ID"/>.
</t>
</section>
<section anchor="example" title="YID CBOR Examples">
<t>
This section show some examples based on the ietf-system module, or on ietf-interfaces module.
</t>
<section anchor="single-module" title="single module form">
<t>
Consider that module ietf-system has been attributed the unique identifier 24. Assume the YANG hash size to be set to 6 bits.
The YANG hash values for 'clock', 'current-datetime', and 'boot-datetime' are calculated by constructing
the schema node identifier for the objects, and then calculating the 5 bit murmur3 hash values (shown
in parentheses) in the figure below. The YIDs are calculated by adding 24*2^6 = 0xc00, leading to:
</t>
<figure>
<artwork align="left"><![CDATA[
/ietf-system:system-state/clock (0x11) YID=0xc11
/ietf-system:system-state/clock/current-datetime (0xb) YID=0xc0b
/ietf-system:system-state/clock/boot-datetime (0x8) YID=0xc08
]]></artwork>
</figure>
<t>
Consider the request for the values of the clock container, as specified with JSON below.
</t>
<figure><artwork align="left">
<![CDATA[
REQ: GET example.com/c/system-state/clock
(Content-Format: application/json)
RES: 2.05 Content (Content-Format: application/cbor+yid)
{ "system-state": {
"clock" : {
"current-datetime" : "2014-10-26T12:16:51Z",
"boot-datetime" : "2014-10-21T03:00:00Z"
}
}
}
]]></artwork></figure>
<t>
Assuming that there are no hash clashes in the module, knowing that only one module is concerned, using the numeric identifiers above, and using 64 bit encoding <xref target ="RFC4648"/> for the URI, the request looks like:
</t>
<figure><artwork align="left">
<![CDATA[
REQ: GET example.com/c/CAR
(Content-Format: application/cbor+yid)
RES: 2.05 Content (Content-Format: application/cbor+yid)
{ 0xc00: {
0x11 : {
-0x6 : "2014-10-26T12:16:51Z",
-0x9 : "2014-10-21T03:00:00Z"
}
}
}
]]></artwork></figure>
<t>
Which creates the corresponding CBOR code to be transported:
</t>
<figure><artwork align="left">
<![CDATA[
a1 # map(1)
19 0c00 # unsigned(3072)
a1 # map(1)
11 # unsigned(17)
a2 # map(2)
25 # negative(5)
74 # text(20)
323031342d31302d32365431323a31363a35315a
# "2014-10-26T12:16:51Z"
28 # negative(8)
74 # text(20)
323031342d31302d32315430333a30303a30305a
# "2014-10-21T03:00:00Z"
]]></artwork>
</figure>
<t>
The example shows that the map keys of the objects are encoded as single bytes, because they their absolute value is smaller than 23. The module identifier takes 12 bits and is encoded as two bytes.
</t>
</section> <!-- single module form -->
<section anchor="local-form" title="Single root form encoding">
<t>
The example of <xref target="example"/> can also be encoded in Single root form encoding by stripping the module identifier. The request in diagnostic JSON looks like:
</t>
<figure><artwork align="left">
<![CDATA[
REQ: GET example.com/c/CAR
(Content-Format: application/cbor+yid)
RES: 2.05 Content (Content-Format: application/cbor+yid)
{ 0xc11 : {
-0x6 : "2014-10-26T12:16:51Z",
-0x9 : "2014-10-21T03:00:00Z"
}
}
]]></artwork></figure>
<t>
In this simple example, the single root form requires less bytes than the single module form. When there are multiple root maps within the module, the module form generates less code because the module is only encoded once and subtracted from the key values of the root maps.
</t>
</section> <!-- local form -->
<section anchor="multi-module" title="Multi module form encoding">
<t>
Suppose there are multiple modules that are requested with the FETCH method. The request is for "clock" from module ietf-system and the other for "neighbor" from module ietf-interfaces. Assume the module identifiers for ietf-system and ietf-interfaces are 24 and 7 respectively.
</t><t>
The YANG hash values for 'neighbor', 'ip', and 'link-layer-address' are calculated by constructing
the schema node identifier for the objects, calculating the 7 bit murmur3 hash values (shown
in parenthesis below, followed by the module identifier calculation 7*2^8 = 0x700. This results in:
</t>
<figure>
<artwork align="left"><![CDATA[
/ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor
(0x78) YID = 0x778
/ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor/ip
(0x40) YID = 0x740
/ietf-interfaces:interfaces/interface/ietf-ip:ipv6/neighbor/
link-layer-address (0x47) YID =0x747
]]></artwork>
</figure>
<t>
The Fetch request and response, assuming no clashes, are shown below:
</t>
<figure><artwork align="left">
<![CDATA[
REQ: FETCH example.com/mg/
(Content-Format: application/cbor+yid)
[{0x30: 0x11}, { 0x700: 0x78}]
RES: 2.05 Content (Content-Format: application/cbor+yid)
[
{ 0xc00: {
0x11 : {
-0x6 : "2014-10-26T12:16:51Z",
-0x9 : "2014-10-21T03:00:00Z"
}
}
},
{ 0x700: {
0x78 : {
-0x38: "fe80::200:f8ff:fe21:67cf",
-0x31: "00:00::10:01:23:45"
}
}
}
]
]]></artwork></figure>
<t>
The corresponding CBOR code is shown in <xref target="CBOR_APP"/>.
</t>
</section> <!-- multi module form -->
<section anchor="multi_clash" title="Multi form encoding with clashes">
<t>
As in <xref target="multi-module"/>, multiple modules that are requested with the FETCH method. The request is for "clock" from module ietf-system and the other for "neighbor" from module ietf-interfaces. Assume the module identifiers for ietf-system and ietf-interfaces are 24 and 7 respectively.
</t><t>
Assume the YANG hash size is still set to 6 bits.
Assume a clash occurred during the hashing of the identifier, /ietf-system:system-state/clock/current-datetime of module ietf-system. Another identifier in ietf-system also has hash value 0xb. The rehashed identifier for "clock" is set to 0x21 with bit 6 set to 1.
</t><t>
The new YANG hash values for 'clock', 'current-datetime', and 'boot-datetime' are shown within parentheses in the figure below:
</t>
<figure>
<artwork align="left"><![CDATA[
/ietf-system:system-state/clock (0x11) YID = 0xc11
/ietf-system:system-state/clock/current-datetime ( 0x21) YID = 0xc21
/ietf-system:system-state/clock/boot-datetime (0x8) YID = 0xc08
]]></artwork>
</figure>
<t>
The Fetch request, including a rehash value, with answer is shown below:
</t>
<figure><artwork align="left">
<![CDATA[
REQ: FETCH example.com/mg/
(Content-Format: application/cbor+yid)
[{0xc00: 0x11}, { 0x700: 0x78}]
RES: 2.05 Content (Content-Format: application/cbor+yid)
[
{ 0xc00: {
0x11 : {
0x10 : "2014-10-26T12:16:51Z",
-0x9 : "2014-10-21T03:00:00Z"
}
}
},
{ 0x700: {
0x78 : {
-0x38: "fe80::200:f8ff:fe21:67cf",
-0x31: "00:00::10:01:23:45"
}
}
}
]
]]></artwork></figure>
<t>
The identifier 0xb of current-datetime has been replaced with the rehash value 0x21.
</t><t>
The corresponding CBOR code is shown in <xref target="CBOR_APP"/>.
</t>
</section> <!-- multi module anchor form -->
</section> <!-- CBOR example -->
<section title="IANA Considerations">
<t>
The Internet media type <xref target="RFC6838"/> for CBOR YANG Identifier are:
<list style="numbers">
<t>
<list style ="symbols">
<t>application/cbor+yid.</t>
<t>Type name: application</t>
<t>Subtype name: cbor+yid</t>
<t>Required parameters: None</t>
<t>Optional parameters: None </t>
<t>Encoding considerations: Resources that use the "application/
cbor+yid" media type are required to conform to the
"application/cbor" media type and are therefore subject to the
same encoding considerations specified in Section 7.3 of
<xref target="RFC7049"/>.</t>
<t>Security considerations: As defined in this specification</t>
<t>Published specification: This specification.</t>
<t>Applications that use this media type: None currently known.</t>
</list>
</t>
<t>
<list style ="symbols">
<t>application/merge-patch+cbor+yid.</t>
<t>Type name: application</t>
<t>Subtype name: merge-patch+cbor+yid</t>
<t>Required parameters: None</t>
<t>Optional parameters: None </t>
<t>Encoding considerations: Resources that use the "application/merge-patch+cbor+yid" media type are required to conform to the
"application/cbor" media type and are therefore subject to the
same encoding considerations specified in Section 7.3 of
<xref target="RFC7049"/>.</t>
<t>Security considerations: As defined in this specification</t>
<t>Published specification: This specification.</t>
<t>Applications that use this media type: None currently known.</t>
</list>
</t>
</list>
</t><t>
Additional information:
<list style="none">
<t>Magic number(s): N/A</t>
<t>File extension(s): N/A</t>
<t>Macintosh file type code(s): N/A</t>
<t>Person and email address to contact for further information: IESG</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: None</t>
<t>Author: Peter van der Stok < consultancy@vanderstok.org > </t>
<t>Change controller: IESG</t>
</list>
</t>
</section> <!-- IANA Considerations -->
<section title="Security considerations">
<t>
Security considerations to be done.
</t>
</section>
<section title="Acknowledgements">
<t>
We are very grateful to Bert Greevenbosch who suggested the use of hashes and specified the use of murmur3.
</t>
</section>
<section title="Changelog">
<t>
xxx
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC6020;
&RFC6838;
&RFC7049;
&RFC7159;
&RFC7252;
&I-D.ietf-core-yang-cbor;
&I-D.bormann-appsawg-cbor-merge-patch;
&I-D.bierman-core-yid;
</references>
<references title="Informative References">
&RFC2578;
&RFC4648;
&RFC6241;
&I-D.ietf-netconf-restconf;
&I-D.vanderstok-core-comi;
</references>
<section anchor="CBOR_APP" title= "CBOR examples">
<t>
The CBOR code belonging to <xref target="local-form"/> is shown below:
</t>
<figure><artwork align="left">
<![CDATA[
a1 # map(1)
19 0c11 # unsigned(3089)
a2 # map(2)
25 # negative(5)
74 # text(20)
323031342d31302d32365431323a31363a35315a
# "2014-10-26T12:16:51Z"
28 # negative(8)
74 # text(20)
323031342d31302d32315430333a30303a30305a
# "2014-10-21T03:00:00Z"
]]></artwork></figure>
<t>
The CBOR code belonging to <xref target="multi-module"/> is shown below:
</t>
<figure><artwork align="left">
<![CDATA[
82 # array(2)
a1 # map(1)
19 0c00 # unsigned(3072)
a1 # map(1)
11 # unsigned(17)
a2 # map(2)
25 # negative(5)
74 # text(20)
323031342d31302d32365431323a31363a35315a
# "2014-10-26T12:16:51Z"
28 # negative(8)
74 # text(20)
323031342d31302d32315430333a30303a30305a
# "2014-10-21T03:00:00Z"
a1 # map(1)
19 0700 # unsigned(1792)
a1 # map(1)
18 78 # unsigned(120)
a2 # map(2)
38 37 # negative(55)
78 18 # text(24)
666538303a3a3230303a663866663a666532313a36376366
# "fe80::200:f8ff:fe21:67cf"
38 30 # negative(48)
72 # text(18)
30303a30303a3a31303a30313a32333a3435
# "00:00::10:01:23:45"
]]></artwork></figure>
<t>
Because the hash codes for the object identifiers of the ietf-interface module are 1 byte long, the corresponding CBOR encoding takes 2 bytes.
</t><t>
The CBOR code belonging to <xref target="multi_clash"/> is shown below:
</t>
<figure><artwork align="left">
82 # array(2)
a1 # map(1)
19 0c00 # unsigned(3072)
a1 # map(1)
11 # unsigned(17)
a2 # map(2)
10 # unsigned(16)
74 # text(20)
323031342d31302d32365431323a31363a35315a
# "2014-10-26T12:16:51Z"
28 # negative(8)
74 # text(20)
323031342d31302d32315430333a30303a30305a
# "2014-10-21T03:00:00Z"
a1 # map(1)
19 0700 # unsigned(1792)
a1 # map(1)
18 78 # unsigned(120)
a2 # map(2)
38 37 # negative(55)
78 18 # text(24)
666538303a3a3230303a663866663a666532313a36376366
# "fe80::200:f8ff:fe21:67cf"
38 30 # negative(48)
72 # text(18)
30303a30303a3a31303a30313a32333a3435
# "00:00::10:01:23:45"
<![CDATA[
]]></artwork></figure>
<t>
The byte 0b, numeric identifier of current-datetime, has been replaced by the one byte 20 due to the hash clash.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:55 |