rfc8746xml2.original.xml   rfc8746.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-cbor-array-tags-08" category="std"> <rfc number="8746" xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true"
ipr="trust200902" docName="draft-ietf-cbor-array-tags-08" category="std"
obsoletes="" updates="" submissionType="IETF" xml:lang="en"
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="CBOR tags for typed arrays">Concise Binary Object Representat <title abbrev="CBOR tags for typed arrays">Concise Binary Object
ion (CBOR) Tags for Typed Arrays</title> Representation (CBOR) Tags for Typed Arrays</title>
<seriesInfo name="RFC" value="8746"/>
<author initials="C." surname="Bormann" fullname="Carsten Bormann" role="edi tor"> <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="edi tor">
<organization>Universität Bremen TZI</organization> <organization ascii="Universitaet Bremen TZI">Universität Bremen TZI</orga nization>
<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 month="February" year="2020"/>
<date year="2019" month="October" day="08"/> <keyword>binary format</keyword>
<keyword>data interchange format</keyword>
<keyword>Internet-Draft</keyword> <keyword>JSON</keyword>
<abstract> <abstract>
<t>The Concise Binary Object Representation (CBOR), as defined in RFC
<t>The Concise Binary Object Representation (CBOR, RFC 7049) is a data 7049, is a data format whose design goals include the possibility of
format whose design goals include the possibility of extremely small extremely small code size, fairly small message size, and extensibility
code size, fairly small message size, and extensibility without the without the need for version negotiation.</t>
need for version negotiation.</t> <t>This document makes use of this extensibility to define a number of
CBOR tags for typed arrays of numeric data, as well as additional
<t>The present document makes use of this extensibility to define a tags for multi-dimensional and homogeneous arrays. It is intended as
number of CBOR tags for typed arrays of numeric data, as well as two the reference document for the IANA registration of the CBOR tags
additional tags for multi-dimensional and homogeneous arrays. It is defined.</t>
intended as the reference document for the IANA registration of the
CBOR tags defined.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>The Concise Binary Object Representation (CBOR) <xref
target="RFC7049" format="default"/> provides for the interchange of
structured data without a requirement for a pre-agreed schema. <xref
target="RFC7049"/> defines a basic set of data types as well as a
tagging mechanism that enables extending the set of data types supported
via an IANA registry.</t>
<t>Recently, a simple form of typed arrays of numeric data has received
interest both in the Web graphics community <xref target="TypedArray"
format="default"/> and in the JavaScript specification (see <eref
target="https://www.ecma-international.org/ecma-262/10.0/index.html#sec-ty
pedarray-objects">Section
22.2</eref> of <xref target="ECMA-ES10" format="default"/>) as well as
in corresponding implementations <xref target="ArrayBuffer"
format="default"/>.</t>
<t>Since these typed arrays may carry significant amounts of data, there
is interest in interchanging them in CBOR without the need of lengthy
conversion of each number in the array. This can also save space
overhead with encoding a type for each element of an array.</t>
<t>This document defines a number of interrelated CBOR tags that cover
these typed arrays, as well as additional tags for multi-dimensional and
homogeneous arrays. It is intended as the reference document for the
IANA registration of the tags defined.</t>
<t>Note that an application that generates CBOR with these tags has
considerable freedom in choosing variants (e.g., with respect to
endianness, embedded type (signed vs. unsigned), and number of bits per
element) or whether a tag defined in this specification is used at all
instead of more basic CBOR. In contrast to representation variants of
single CBOR numbers, there is no representation that could be identified
as "preferred". If deterministic encoding is desired in a CBOR-based
protocol making use of these tags, the protocol has to define which of
the encoding variants are used for each individual case.</t>
<section anchor="intro" title="Introduction"> <section anchor="terms" numbered="true" toc="default">
<name>Terminology</name>
<t>The Concise Binary Object Representation (CBOR, <xref target="RFC7049"/>) pro
vides
for the interchange of structured data without a requirement for a
pre-agreed schema.
RFC 7049 defines a basic set of data types, as well as a tagging
mechanism that enables extending the set of data types supported via
an IANA registry.</t>
<t>Recently, a simple form of typed arrays of numeric data has received
interest both in the Web graphics community <xref target="TypedArray"/> and in
the JavaScript specification <xref target="TypedArrayES6"/>, as well as in
corresponding implementations <xref target="ArrayBuffer"/>.</t>
<t>Since these typed arrays may carry significant amounts of data, there
is interest in interchanging them in CBOR without the need of lengthy
conversion of each number in the array. This can also save space
overhead with encoding a type for each element of an array.</t>
<t>This document defines a number of interrelated CBOR tags that cover
these typed arrays, as well as two additional tags for
multi-dimensional and homogeneous arrays.
It is intended as the reference document for the IANA registration of
the tags defined.</t>
<t>Note that an application that generates CBOR with these tags has
considerable freedom in choosing variants, e.g., with respect to
endianness, embedded type (signed vs. unsigned), and number of bits
per element, or whether a tag defined in this specification is used at
all instead of more basic CBOR. In contrast to representation
variants of single CBOR numbers, there is no representation that could
be identified as “preferred”. If deterministic encoding is desired in
a CBOR-based protocol making use of these tags, the protocol has to
define which of the encoding variants are used in which case.</t>
<section anchor="terms" title="Terminology">
<!--
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
RFC 2119 {{ !RFC2119}}.
-->
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.
Where bit arithmetic is explained, this document uses the notation
familiar from the programming language C <xref target="C"/> (including C++14’s 0
bnnn
binary literals <xref target="Cplusplus"/>), except that the operator “**” stand
s for
exponentiation.</t>
<t>The term “array” is used in a general sense in this document, unless
further specified. The term “classical CBOR array” describes an array
represented with CBOR major type 4. A “homogeneous array” is an array
of elements that are all of the same type (the term is neutral as to whether
that is a representation type or an application data model type).</t>
<t>The terms “big endian” and “little endian” are used to indicate a most
significant byte first (MSB first) representation of integers, and a
least significant byte first (LSB first) representation, respectively.</t>
</section>
</section>
<section anchor="typedarrays" title="Typed Arrays">
<t>Typed arrays are homogeneous arrays of numbers, all of which are
encoded in a single form of binary representation. The concatenation
of these representations is encoded as a single CBOR byte string
(major type 2), enclosed by a single tag indicating the type and
encoding of all the numbers represented in the byte string.</t>
<section anchor="dataTypes" title="Types of numbers">
<t>Three classes of numbers are of interest: unsigned integers (uint),
signed integers (two’s complement, sint), and IEEE 754 binary floating
point numbers (which are always signed). For each of these classes,
there are multiple representation lengths in active use:</t>
<texttable title="Length values" anchor="lengths">
<ttcol align='left'>Length ll</ttcol>
<ttcol align='left'>uint</ttcol>
<ttcol align='left'>sint</ttcol>
<ttcol align='left'>float</ttcol>
<c>0</c>
<c>uint8</c>
<c>sint8</c>
<c>binary16</c>
<c>1</c>
<c>uint16</c>
<c>sint16</c>
<c>binary32</c>
<c>2</c>
<c>uint32</c>
<c>sint32</c>
<c>binary64</c>
<c>3</c>
<c>uint64</c>
<c>sint64</c>
<c>binary128</c>
</texttable>
<t>Here, sintN stands for a signed integer of exactly N bits (for
instance, sint16), and uintN stands for an unsigned integer of exactly
N bits (for instance, uint32). The name binaryN stands for the number
form of the same name defined in IEEE 754 <xref target="IEEE754"/>.</t>
<t>Since one objective of these tags is to be able to directly ship the
ArrayBuffers underlying the Typed Arrays without re-encoding them, and
these may be either in big endian (network byte order) or in little
endian form, we need to define tags for both variants.</t>
<t>In total, this leads to 24 variants. In the tag, we need to express
the choice between integer and floating point, the signedness (for
integers), the endianness, and one of the four length values.</t>
<t>In order to simplify implementation, a range of tags is being
allocated that allows retrieving all this information from the bits of
the tag: Tag values from 64 to 87. <!-- (0x40 to 0x57) --></t>
<t>The value is split up into 5 bit fields: 0b010_f_s_e_ll, as
detailed in <xref target="fields"/>.</t>
<texttable title="Bit fields in the low 8 bits of the tag" anchor="fields">
<ttcol align='left'>Field</ttcol>
<ttcol align='left'>Use</ttcol>
<c>0b010</c>
<c>the constant bits 0, 1, 0</c>
<c>f</c>
<c>0 for integer, 1 for float</c>
<c>s</c>
<c>0 for float or unsigned integer, 1 for signed integer</c>
<c>e</c>
<c>0 for big endian, 1 for little endian</c>
<c>ll</c>
<c>A number for the length (<xref target="lengths"/>).</c>
</texttable>
<t>The number of bytes in each array element can then be calculated by
<spanx style="verb">2**(f + ll)</spanx> (or <spanx style="verb">1 &lt;&lt; (f +
ll)</spanx> in a typical programming language).
(Notice that 0f and ll are the two least significant bits, respectively, of each
nibble (4bit) in the byte.)</t>
<t>In the CBOR representation, the total number of elements in the array
is not expressed explicitly, but implied from the length of the byte
string and the length of each representation. It can be
computed from the length, in bytes, of the byte string comprising the
representation of the array by inverting the previous formula:
<spanx style="verb">bytelength &gt;&gt; (f + ll)</spanx>.</t>
<t>For the uint8/sint8 values, the endianness is redundant.
Only the tag for the big endian variant is used and assigned as such.
The Tag that would signify the little endian variant of sint8 MUST NOT
be used, its tag number is marked as reserved.
As a special case, the Tag that would signify the little
endian variant of uint8 is instead assigned to signify that the numbers in the a
rray are using clamped
conversion from integers, as described in more detail in Section 7.1.11 (<spanx
style="verb">ToUint8Clamp</spanx>)
of the ES6 JavaScript specification <xref target="TypedArrayES6"/>; the assumpti
on
here is that a program-internal representation of this array after
decoding would be marked this way for further processing, providing
“roundtripping” of JavaScript typed arrays through CBOR.</t>
<t>IEEE 754 binary floating numbers are always signed. Therefore, for
the float variants (<spanx style="verb">f</spanx> == 1), there is no need to dis
tinguish between
signed and unsigned variants; the <spanx style="verb">s</spanx> bit is always ze
ro. The Tag
numbers where <spanx style="verb">s</spanx> would be one (which would have Tag v
alues 88 to 95)
remain free to use by other specifications.</t>
</section>
</section>
<section anchor="additional-array-tags" title="Additional Array Tags">
<t>This specification defines three additional array tags.
The Multi-dimensional Array tags can be combined with classical CBOR
arrays as well as with Typed Arrays in order to build
multi-dimensional arrays with constant numbers of elements in the
sub-arrays.
The Homogeneous Array tag can be used as a signal by an application to
identify a classical CBOR array as a homogeneous array,
even when a Typed Array does not apply.</t>
<section anchor="multi-dimensional-array" title="Multi-dimensional Array">
<t>A multi-dimensional array is represented as a tagged array that
contains two (one-dimensional) arrays. The first array defines the
dimensions of the
multi-dimensional array (in the sequence of outer dimensions towards
inner dimensions) while the second array represents the contents
of the multi-dimensional array. If the second array is itself tagged
as a Typed Array then the element type of the multi-dimensional array
is known to be the same type as that of the Typed Array.</t>
<t>Two tags are defined by this document, one for elements arranged in <t>
row-major order, and one for column-major order <xref target="RowColMajor"/>.</t The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<section anchor="row-major-order" title="Row-major Order"> <t>The term "byte" is used in its now-customary sense as a synonym for
"octet". Where bit arithmetic is explained, this document uses
familiar notation from the programming language C <xref target="C"
format="default"/> (including C++14's 0bnnn binary literals <xref
target="CPlusPlus" format="default"/>) with the exception of the
operator "**", which stands for exponentiation.</t>
<t>The term "array" is used in a general sense in this document unless
further specified. The term "classical CBOR array" describes an array
represented with CBOR major type 4. A "homogeneous array" is an array
of elements that are all the same type (the term is neutral as to
whether that is a representation type or an application data model
type).</t>
<t>The terms "big endian" and "little endian" are used to indicate a
most significant byte first (MSB first) representation of integers and
a least significant byte first (LSB first) representation,
respectively.</t>
</section>
</section>
<t><list style="hanging"> <section anchor="typedarrays" numbered="true" toc="default">
<t hangText='Tag:'> <name>Typed Arrays</name>
40</t> <t>Typed arrays are homogeneous arrays of numbers, all of which are
<t hangText='Data Item:'> encoded in a single form of binary representation. The concatenation of
array (major type 4) of two arrays, one array (major type 4) of these representations is encoded as a single CBOR byte string (major
dimensions, which are unsigned integers distinct from zero, and one type 2), enclosed by a single tag indicating the type and encoding of
array (either a CBOR array of major type 4, or a Typed Array, or a all the numbers represented in the byte string.</t>
Homogeneous Array) of elements</t> <section anchor="dataTypes" numbered="true" toc="default">
</list></t> <name>Types of Numbers</name>
<t>Three classes of numbers are of interest: unsigned integers (uint),
signed integers (two's complement, sint), and IEEE 754 binary floating
point numbers (which are always signed). For each of these classes,
there are multiple representation lengths in active use:</t>
<table anchor="lengths" align="center">
<name>Length Values</name>
<thead>
<tr>
<th align="left">Length ll</th>
<th align="left">uint</th>
<th align="left">sint</th>
<th align="left">float</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">uint8</td>
<td align="left">sint8</td>
<td align="left">binary16</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">uint16</td>
<td align="left">sint16</td>
<td align="left">binary32</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">uint32</td>
<td align="left">sint32</td>
<td align="left">binary64</td>
</tr>
<tr>
<td align="left">3</td>
<td align="left">uint64</td>
<td align="left">sint64</td>
<td align="left">binary128</td>
</tr>
</tbody>
</table>
<t>Here, sintN stands for a signed integer of exactly N bits (for
instance, sint16), and uintN stands for an unsigned integer of exactly
N bits (for instance, uint32). The name binaryN stands for the number
form of the same name defined in IEEE 754 <xref target="IEEE754"
format="default"/>.</t>
<t>Data in the second array consists of consecutive values where the last <t>Since one objective of these tags is to be able to directly ship the
dimension is considered contiguous (row-major order).</t> ArrayBuffers underlying the Typed Arrays without re-encoding them, and these
may be either in big-endian (network byte order) or in little-endian form, we
need to define tags for both variants.</t>
<t>In total, this leads to 24 variants. In the tag, we need to
express the choice between integer and floating point, the signedness
(for integers), the endianness, and one of the four length values.</t>
<t>In order to simplify implementation, a range of tags is being
allocated that allows retrieving all this information from the bits of
the tag: tag values from 64 to 87.
</t>
<t>The value is split up into 5 bit fields: 0b010, f, s, e, and ll as
detailed in <xref target="fields" format="default"/>.</t>
<t><xref target="ex-multidim"/> shows a declaration of a two-dimensional array i <table anchor="fields" align="center">
n the <name>Bit Fields in the Low 8 Bits of the Tag</name>
C language, a representation of that in CBOR using both a <thead>
multidimensional array tag and a typed array tag.</t> <tr>
<th align="left">Field</th>
<th align="left">Use</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0b010</td>
<td align="left">the constant bits 0, 1, 0</td>
</tr>
<tr>
<td align="left">f</td>
<td align="left">0 for integer, 1 for float</td>
</tr>
<tr>
<td align="left">s</td>
<td align="left">0 for float or unsigned integer, 1 for signed int
eger</td>
</tr>
<tr>
<td align="left">e</td>
<td align="left">0 for big endian, 1 for little endian</td>
</tr>
<tr>
<td align="left">ll</td>
<td align="left">A number for the length (<xref target="lengths" f
ormat="default"/>).</td>
</tr>
</tbody>
</table>
<figure title="Multi-dimensional array in C and CBOR" anchor="ex-multidim"><artw <t>The number of bytes in each array element can then be calculated by
ork><![CDATA[ <tt>2**(f + ll)</tt> (or <tt>1 &lt;&lt; (f + ll)</tt> in a typical
programming language). (Notice that 0f and ll are the two least
significant bits, respectively, of each 4-bit nibble in the byte.)</t>
<t>In the CBOR representation, the total number of elements in the
array is not expressed explicitly but is implied from the length of
the byte string and the length of each representation. It can be
computed from the length, in bytes, of the byte string comprising the
representation of the array by inverting the previous formula:
<tt>bytelength &gt;&gt; (f + ll)</tt>.</t>
<t>For the uint8/sint8 values, the endianness is redundant. Only the
tag for the big-endian variant is used and assigned as such. The tag
that would signify the little-endian variant of sint8 <bcp14>MUST
NOT</bcp14> be used; its tag number is marked as reserved. As a
special case, the tag that would signify the little-endian variant of
uint8 is instead assigned to signify that the numbers in the array are
using clamped conversion from integers, as described in more detail in
<eref
target="http://www.ecma-international.org/ecma-262/6.0/#sec-touint8clamp
">Section&nbsp;7.1.11</eref>
of the ES10 JavaScript specification (<tt>ToUint8Clamp</tt>) <xref
target="ECMA-ES10" format="default"/>; the assumption here is that a
program-internal representation of this array after decoding would be
marked this way for further processing providing "roundtripping" of
JavaScript-typed arrays through CBOR.</t>
<t>IEEE 754 binary floating numbers are always signed. Therefore, for
the float variants (<tt>f</tt> == 1), there is no need to distinguish
between signed and unsigned variants; the <tt>s</tt> bit is always
zero. The tag numbers where <tt>s</tt> would be one (which would have
tag values 88 to 95) remain free to use by other specifications.</t>
</section>
</section>
<section anchor="additional-array-tags" numbered="true" toc="default">
<name>Additional Array Tags</name>
<t>This specification defines three additional array tags. The
Multi-dimensional Array tags can be combined with classical CBOR arrays
as well as with Typed Arrays in order to build multi-dimensional arrays
with constant numbers of elements in the sub-arrays. The Homogeneous
Array tag can be used as a signal by an application to identify a
classical CBOR array as a homogeneous array, even when a Typed Array
does not apply.</t>
<section anchor="multi-dimensional-array" numbered="true" toc="default">
<name>Multi-dimensional Array</name>
<t>A multi-dimensional array is represented as a tagged array that
contains two (one-dimensional) arrays. The first array defines the
dimensions of the multi-dimensional array (in the sequence of outer
dimensions towards inner dimensions) while the second array represents
the contents of the multi-dimensional array. If the second array is
itself tagged as a Typed Array, then the element type of the
multi-dimensional array is known to be the same type as that of the
Typed Array.</t>
<t>Two tags are defined by this document: one for elements arranged in
row-major order and another for column-major order <xref
target="RowColMajor" format="default"/>.</t>
<section anchor="row-major-order" numbered="true" toc="default">
<name>Row-Major Order</name>
<dl newline="false" spacing="normal">
<dt>Tag:</dt>
<dd>
40</dd>
<dt>Data Item:</dt>
<dd>
Array (major type 4) of two arrays: one array (major type 4) of dimensions,
which are unsigned integers distinct from zero; and one array (any one of a
CBOR array of major type 4, a Typed Array, or a Homogeneous Array) of
elements.</dd>
</dl>
<t>Data in the second array consists of consecutive values where the
last dimension is considered contiguous (row-major order).</t>
<t><xref target="ex-multidim" format="default"/> shows a declaration
of a two-dimensional array in the C language, a representation of
that in CBOR using both a multi-dimensional array tag and a typed
array tag.</t>
<figure anchor="ex-multidim">
<name>Multi-dimensional Array in C and CBOR</name>
<sourcecode type="C">
uint16_t a[2][3] = { uint16_t a[2][3] = {
{2, 4, 8}, /* row 0 */ {2, 4, 8}, /* row 0 */
{4, 16, 256}, {4, 16, 256},
}; };
<Tag 40&gt; # multi-dimensional array tag <Tag 40&gt; # multi-dimensional array tag
82 # array(2) 82 # array(2)
82 # array(2) 82 # array(2)
02 # unsigned(2) 1st Dimension 02 # unsigned(2) 1st Dimension
03 # unsigned(3) 2nd Dimension 03 # unsigned(3) 2nd Dimension
<Tag 65&gt; # uint16 array <Tag 65&gt; # uint16 array
4c # byte string(12) 4c # byte string(12)
0002 # unsigned(2) 0002 # unsigned(2)
0004 # unsigned(4) 0004 # unsigned(4)
0008 # unsigned(8) 0008 # unsigned(8)
0004 # unsigned(4) 0004 # unsigned(4)
0010 # unsigned(16) 0010 # unsigned(16)
0100 # unsigned(256) 0100 # unsigned(256)
]]></artwork></figure> </sourcecode>
</figure>
<t><xref target="ex-multidim1"/> shows the same two-dimensional array using the <t><xref target="ex-multidim1" format="default"/> shows the same
multidimensional array tag in conjunction with a basic CBOR array two-dimensional array using the multi-dimensional array tag in
(which, with the small numbers chosen for the example, happens to be conjunction with a basic CBOR array (which, with the small numbers
shorter).</t> chosen for the example, happens to be shorter).</t>
<figure anchor="ex-multidim1">
<figure title="Multi-dimensional array using basic CBOR array" anchor="ex-multid <name>Multi-dimensional Array Using Basic CBOR Array</name>
im1"><artwork><![CDATA[ <sourcecode type="CBOR">
<Tag 40> # multi-dimensional array tag &lt;Tag 40&gt; # multi-dimensional array tag
82 # array(2) 82 # array(2)
82 # array(2) 82 # array(2)
02 # unsigned(2) 1st Dimension 02 # unsigned(2) 1st Dimension
03 # unsigned(3) 2nd Dimension 03 # unsigned(3) 2nd Dimension
86 # array(6) 86 # array(6)
02 # unsigned(2) 02 # unsigned(2)
04 # unsigned(4) 04 # unsigned(4)
08 # unsigned(8) 08 # unsigned(8)
04 # unsigned(4) 04 # unsigned(4)
10 # unsigned(16) 10 # unsigned(16)
19 0100 # unsigned(256) 19 0100 # unsigned(256)
]]></artwork></figure> </sourcecode>
</section>
<section anchor="column-major-order" title="Column-Major order">
<t>The multidimensional arrays specified in the previous
sub-subsection are in “row major” order, which is the preferred order
for the purposes of this specification. An analogous representation
that uses “column major” order arrays is provided in this subsection
under the tag 1040, as illustrated in <xref target="ex-multidim2"/>.</t>
<t><list style="hanging">
<t hangText='Tag:'>
1040</t>
<t hangText='Data Item:'>
as with tag 40, except that the data in the second array consists of
consecutive values where the first dimension is considered contiguous
(column-major order).</t>
</list></t>
<figure title="Multi-dimensional array using basic CBOR </figure>
array, column major order" anchor="ex-multidim2"><artwork><![CDATA[ </section>
<Tag 1040> # multi-dimensional array tag, column major order <section anchor="column-major-order" numbered="true" toc="default">
<name>Column-Major Order</name>
<t>The multi-dimensional arrays specified in the previous
sub-subsection are in "row major" order, which is the preferred
order for the purposes of this specification. An analogous
representation that uses "column major" order arrays is provided in
this subsection under the tag 1040, as illustrated in <xref
target="ex-multidim2" format="default"/>.</t>
<dl newline="false" spacing="normal">
<dt>Tag:</dt>
<dd>
1040</dd>
<dt>Data Item:</dt>
<dd>
The same as tag 40, except the data in the second array consists of
consecutive values where the first dimension is considered contiguous
(column-major order).</dd>
</dl>
<figure anchor="ex-multidim2">
<name>Multi-dimensional Array Using Basic CBOR Array, Column-Major O
rder</name>
<sourcecode type="CBOR">
&lt;Tag 1040&gt; # multi-dimensional array tag, column-major order
82 # array(2) 82 # array(2)
82 # array(2) 82 # array(2)
02 # unsigned(2) 1st Dimension 02 # unsigned(2) 1st Dimension
03 # unsigned(3) 2nd Dimension 03 # unsigned(3) 2nd Dimension
86 # array(6) 86 # array(6)
02 # unsigned(2) 02 # unsigned(2)
04 # unsigned(4) 04 # unsigned(4)
04 # unsigned(4) 04 # unsigned(4)
10 # unsigned(16) 10 # unsigned(16)
08 # unsigned(8) 08 # unsigned(8)
19 0100 # unsigned(256) 19 0100 # unsigned(256)
]]></artwork></figure> </sourcecode>
</section>
</section>
<section anchor="homogeneous-array" title="Homogeneous Array">
<t><list style="hanging">
<t hangText='Tag:'>
41</t>
<t hangText='Data Item:'>
array (major type 4)</t>
</list></t>
<t>This tag identifies the classical CBOR array (a one-dimensional array)
tagged by it as a homogeneous array, that is, it has elements that are
all of the same application model data type. The element type of the
array is thus determined by the application model data type of the
first array element.</t>
<t>This can be used in application data models that apply specific
semantics to homogeneous arrays. Also, in certain cases,
implementations in strongly typed languages may be able to create
native homogeneous arrays of specific types instead of ordered lists
while decoding. Which CBOR data items constitute elements of the same
application type is specific to the application.</t>
<t><xref target="ex-homogeneous"/> shows an example for a homogeneous array of
booleans in C++ <xref target="Cplusplus"/> and CBOR.</t>
<figure title="Homogeneous array in C++ and CBOR" anchor="ex-homogeneous"><artwo </figure>
rk><![CDATA[ </section>
</section>
<section anchor="homogeneous-array" numbered="true" toc="default">
<name>Homogeneous Array</name>
<dl newline="false" spacing="normal">
<dt>Tag:</dt>
<dd>
41</dd>
<dt>Data Item:</dt>
<dd>
Array (major type 4)</dd>
</dl>
<t>This tag identifies the classical CBOR array (a one-dimensional
array) tagged by it as a homogeneous array, that is, it has elements
that are all of the same application model data type. The element
type of the array is therefore determined by the application model
data type of the first array element.</t>
<t>This can be used in application data models that apply specific
semantics to homogeneous arrays. Also, in certain cases,
implementations in strongly typed languages may be able to create
native homogeneous arrays of specific types instead of ordered lists
while decoding. Which CBOR data items constitute elements of the same
application type is specific to the application.</t>
<t><xref target="ex-homogeneous" format="default"/> shows an example
for a homogeneous array of booleans in C++ <xref target="CPlusPlus"
format="default"/> and CBOR.</t>
<figure anchor="ex-homogeneous">
<name>Homogeneous Array in C++ and CBOR</name>
<sourcecode type="C++">
bool boolArray[2] = { true, false }; bool boolArray[2] = { true, false };
<Tag 41&gt; # Homogeneous Array Tag <Tag 41&gt; # Homogeneous Array Tag
82 #array(2) 82 #array(2)
F5 # true F5 # true
F4 # false F4 # false
]]></artwork></figure> </sourcecode>
<t><xref target="ex-homogeneous1"/> extends the example with a more complex stru
cture.</t>
<figure title="Homogeneous array in C++ and CBOR" anchor="ex-homogeneous1"><artw </figure>
ork><![CDATA[ <t><xref target="ex-homogeneous1" format="default"/> extends the
example with a more complex structure.</t>
<figure anchor="ex-homogeneous1">
<name>Homogeneous Array in C++ and CBOR</name>
<sourcecode type="C++">
typedef struct { typedef struct {
bool active; bool active;
int value; int value;
} foo; } foo;
foo myArray[2] = { {true, 3}, {true, -4} }; foo myArray[2] = { {true, 3}, {true, -4} };
<Tag 41&gt; <Tag 41&gt;
82 # array(2) 82 # array(2)
82 # array(2) 82 # array(2)
F5 # true F5 # true
03 # 3 03 # 3
82 # array(2) 82 # array(2)
F5 # true F5 # true
23 # -4 23 # -4
]]></artwork></figure> </sourcecode>
</figure>
</section> </section>
</section> </section>
<section anchor="discussion" title="Discussion"> <section anchor="discussion" numbered="true" toc="default">
<name>Discussion</name>
<t>Support for both little- and big-endian representation may seem out of <t>Support for both little- and big-endian representation may seem out
character with CBOR, which is otherwise fully big endian. This of character with CBOR, which is otherwise fully big endian. This
support is in line with the intended use of the typed arrays and the support is in line with the intended use of the typed arrays and the
objective not to require conversion of each array element.</t> objective not to require conversion of each array element.</t>
<t>This specification allocates a sizable chunk out of the single-byte
<t>This specification allocates a sizable chunk out of the single-byte tag space. This use of code point space is justified by the wide use of
tag space. This use of code point space is justified by the wide use typed arrays in data interchange.</t>
of typed arrays in data interchange.</t> <t>Providing a column-major order variant of the multi-dimensional array
may seem superfluous to some and useful to others. It is cheap to
<t>Providing a column-major order variant of the multi-dimensional array define the additional tag so that it is available when actually needed.
may seem superfluous to some, and useful to others. It is cheap to Allocating it out of a different number space makes the preference for
define the additional tag so it is available when actually needed. row-major evident.</t>
Allocating it out of a different number space makes the preference for <t>Applying a Homogeneous Array tag to a Typed Array would usually be
row-major evident.</t> redundant and is therefore not provided by the present
specification.</t>
<t>Applying a Homogeneous Array tag to a Typed Array would usually be <t/>
redundant and is therefore not provided by the present specification.</t> </section>
<section anchor="cddl-typenames" numbered="true" toc="default">
<t><vspace blankLines='999' /></t> <name>CDDL Typenames</name>
<t>For use with CDDL <xref target="RFC8610" format="default"/>, the
</section> typenames defined in <xref target="tag-cddl" format="default"/> are
<section anchor="cddl-typenames" title="CDDL typenames"> recommended:</t>
<figure anchor="tag-cddl">
<t>For the use with CDDL <xref target="RFC8610"/>, the <name>Recommended Typenames for CDDL</name>
typenames defined in <xref target="tag-cddl"/> are recommended:</t> <sourcecode type="CDDL">
<figure title="Recommended typenames for CDDL" anchor="tag-cddl"><artwork type="
CDDL"><![CDATA[
ta-uint8 = #6.64(bstr) ta-uint8 = #6.64(bstr)
ta-uint16be = #6.65(bstr) ta-uint16be = #6.65(bstr)
ta-uint32be = #6.66(bstr) ta-uint32be = #6.66(bstr)
ta-uint64be = #6.67(bstr) ta-uint64be = #6.67(bstr)
ta-uint8-clamped = #6.68(bstr) ta-uint8-clamped = #6.68(bstr)
ta-uint16le = #6.69(bstr) ta-uint16le = #6.69(bstr)
ta-uint32le = #6.70(bstr) ta-uint32le = #6.70(bstr)
ta-uint64le = #6.71(bstr) ta-uint64le = #6.71(bstr)
ta-sint8 = #6.72(bstr) ta-sint8 = #6.72(bstr)
ta-sint16be = #6.73(bstr) ta-sint16be = #6.73(bstr)
skipping to change at line 459 skipping to change at line 479
ta-sint32le = #6.78(bstr) ta-sint32le = #6.78(bstr)
ta-sint64le = #6.79(bstr) ta-sint64le = #6.79(bstr)
ta-float16be = #6.80(bstr) ta-float16be = #6.80(bstr)
ta-float32be = #6.81(bstr) ta-float32be = #6.81(bstr)
ta-float64be = #6.82(bstr) ta-float64be = #6.82(bstr)
ta-float128be = #6.83(bstr) ta-float128be = #6.83(bstr)
ta-float16le = #6.84(bstr) ta-float16le = #6.84(bstr)
ta-float32le = #6.85(bstr) ta-float32le = #6.85(bstr)
ta-float64le = #6.86(bstr) ta-float64le = #6.86(bstr)
ta-float128le = #6.87(bstr) ta-float128le = #6.87(bstr)
homogeneous<array> = #6.41(array) homogeneous&lt;array&gt; = #6.41(array)
multi-dim<dim, array> = #6.40([dim, array]) multi-dim&lt;dim, array&gt; = #6.40([dim, array])
multi-dim-column-major<dim, array> = #6.1040([dim, array]) multi-dim-column-major&lt;dim, array&gt; = #6.1040([dim, array])
]]></artwork></figure> </sourcecode>
<t><vspace blankLines='999' /></t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA has allocated the tags in <xref target="tab-tag-values"/>, with the
present document as the specification reference. (The reserved value
is reserved for a future revision of typed array tags.)</t>
<t>The allocations came out of the “specification required” space
(24..255), with the exception of 1040, which came out of the “first
come first served” space (256..).</t>
<texttable title="Values for Tags" anchor="tab-tag-values">
<ttcol align='right'>Tag</ttcol>
<ttcol align='left'>Data Item</ttcol>
<ttcol align='left'>Semantics</ttcol>
<c>64</c>
<c>byte string</c>
<c>uint8 Typed Array</c>
<c>65</c>
<c>byte string</c>
<c>uint16, big endian, Typed Array</c>
<c>66</c>
<c>byte string</c>
<c>uint32, big endian, Typed Array</c>
<c>67</c>
<c>byte string</c>
<c>uint64, big endian, Typed Array</c>
<c>68</c>
<c>byte string</c>
<c>uint8 Typed Array, clamped arithmetic</c>
<c>69</c>
<c>byte string</c>
<c>uint16, little endian, Typed Array</c>
<c>70</c>
<c>byte string</c>
<c>uint32, little endian, Typed Array</c>
<c>71</c>
<c>byte string</c>
<c>uint64, little endian, Typed Array</c>
<c>72</c>
<c>byte string</c>
<c>sint8 Typed Array</c>
<c>73</c>
<c>byte string</c>
<c>sint16, big endian, Typed Array</c>
<c>74</c>
<c>byte string</c>
<c>sint32, big endian, Typed Array</c>
<c>75</c>
<c>byte string</c>
<c>sint64, big endian, Typed Array</c>
<c>76</c>
<c>byte string</c>
<c>(reserved)</c>
<c>77</c>
<c>byte string</c>
<c>sint16, little endian, Typed Array</c>
<c>78</c>
<c>byte string</c>
<c>sint32, little endian, Typed Array</c>
<c>79</c>
<c>byte string</c>
<c>sint64, little endian, Typed Array</c>
<c>80</c>
<c>byte string</c>
<c>IEEE 754 binary16, big endian, Typed Array</c>
<c>81</c>
<c>byte string</c>
<c>IEEE 754 binary32, big endian, Typed Array</c>
<c>82</c>
<c>byte string</c>
<c>IEEE 754 binary64, big endian, Typed Array</c>
<c>83</c>
<c>byte string</c>
<c>IEEE 754 binary128, big endian, Typed Array</c>
<c>84</c>
<c>byte string</c>
<c>IEEE 754 binary16, little endian, Typed Array</c>
<c>85</c>
<c>byte string</c>
<c>IEEE 754 binary32, little endian, Typed Array</c>
<c>86</c>
<c>byte string</c>
<c>IEEE 754 binary64, little endian, Typed Array</c>
<c>87</c>
<c>byte string</c>
<c>IEEE 754 binary128, little endian, Typed Array</c>
<c>40</c>
<c>array of two arrays*</c>
<c>Multi-dimensional Array, row-major order</c>
<c>1040</c>
<c>array of two arrays*</c>
<c>Multi-dimensional Array, column-major order</c>
<c>41</c>
<c>array</c>
<c>Homogeneous Array</c>
</texttable>
<t>*) 40 or 1040 data item: second element of outer array in data item is
native CBOR array (major type 4) or Typed Array (one of Tag 64..87)</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations of RFC 7049 apply; special attention is </figure>
drawn to the second paragraph of Section 8 of RFC 7049.</t> <t/>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>The Tag for homogeneous arrays makes a promise about its tagged data <t>IANA has allocated the tags in <xref target="tab-tag-values"
item that a maliciously constructed CBOR input can then choose to format="default"/> using this document as the specification reference.
ignore. As always, the decoder therefore has to ensure that it is not (The reserved value is for a future revision of typed array tags.)</t>
driven into an undefined state by array elements that do not fulfill <t>The allocations were assigned from the "specification required" space
the promise and that it does continue to fulfill its API contract in (24..255) with the exception of 1040, which was assigned from the "first c
this case as well.</t> ome
first served" space (256..).</t>
<table anchor="tab-tag-values" align="center">
<name>Values for Tags</name>
<thead>
<tr>
<th align="right">Tag</th>
<th align="left">Data Item</th>
<th align="left">Semantics</th>
</tr>
</thead>
<tbody>
<t>As with all formats that are used for data interchange, an attacker <tr>
may have control over the shape of the data delivered as input to the <td align="right">40</td>
application, which therefore needs to validate that shape before it <td align="left">array of two arrays*</td>
makes it the basis of its further processing. One unique aspect that <td align="left">Multi-dimensional Array, row-major order</td>
typed arrays add to this is that an attacker might substitute a </tr>
Uint8ClampedArray for where the application expects a Uint8Array, or <tr>
vice versa, potentially leading to very different (and unexpected) <td align="right">41</td>
processing semantics of the in-memory data structures constructed. <td align="left">array</td>
Applications that could be affected by this therefore will need to be <td align="left">Homogeneous Array</td>
careful about making this distinction in their input validation.</t> </tr>
<tr>
<td align="right">64</td>
<td align="left">byte string</td>
<td align="left">uint8 Typed Array</td>
</tr>
<tr>
<td align="right">65</td>
<td align="left">byte string</td>
<td align="left">uint16, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">66</td>
<td align="left">byte string</td>
<td align="left">uint32, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">67</td>
<td align="left">byte string</td>
<td align="left">uint64, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">68</td>
<td align="left">byte string</td>
<td align="left">uint8 Typed Array, clamped arithmetic</td>
</tr>
<tr>
<td align="right">69</td>
<td align="left">byte string</td>
<td align="left">uint16, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">70</td>
<td align="left">byte string</td>
<td align="left">uint32, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">71</td>
<td align="left">byte string</td>
<td align="left">uint64, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">72</td>
<td align="left">byte string</td>
<td align="left">sint8 Typed Array</td>
</tr>
<tr>
<td align="right">73</td>
<td align="left">byte string</td>
<td align="left">sint16, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">74</td>
<td align="left">byte string</td>
<td align="left">sint32, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">75</td>
<td align="left">byte string</td>
<td align="left">sint64, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">76</td>
<td align="left">byte string</td>
<td align="left">(reserved)</td>
</tr>
<tr>
<td align="right">77</td>
<td align="left">byte string</td>
<td align="left">sint16, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">78</td>
<td align="left">byte string</td>
<td align="left">sint32, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">79</td>
<td align="left">byte string</td>
<td align="left">sint64, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">80</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary16, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">81</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary32, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">82</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary64, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">83</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary128, big endian, Typed Array</td>
</tr>
<tr>
<td align="right">84</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary16, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">85</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary32, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">86</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary64, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">87</td>
<td align="left">byte string</td>
<td align="left">IEEE 754 binary128, little endian, Typed Array</td>
</tr>
<tr>
<td align="right">1040</td>
<td align="left">array of two arrays*</td>
<td align="left">Multi-dimensional Array, column-major order</td>
</tr>
<t><vspace blankLines='999' /></t> </tbody>
</table>
</section> <t>*40 or 1040 data item: The second element of the outer array in the data
item is a native CBOR array (major type 4) or Typed Array (one of tag
64..87)</t>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations of <xref target="RFC7049"/> apply;
special attention is drawn to the second paragraph of <xref
target="RFC7049" sectionFormat="of" section="8"/>.</t>
<t>The tag for homogeneous arrays makes a promise about its tagged data
item, which a maliciously constructed CBOR input can then choose to
ignore. As always, the decoder therefore has to ensure that it is not
driven into an undefined state by array elements that do not fulfill the
promise, and that it does continue to fulfill its API contract in this
case as well.</t>
<t>As with all formats that are used for data interchange, an attacker
may have control over the shape of the data delivered as input to the
application, which therefore needs to validate that shape before it
makes it the basis of its further processing. One unique aspect that
typed arrays add to this is that an attacker might substitute a
Uint8ClampedArray for where the application expects a Uint8Array, or
vice versa, potentially leading to very different (and unexpected)
processing semantics of the in-memory data structures constructed.
Applications that could be affected by this will therefore need to be
careful about making this distinction in their input validation.</t>
<t/>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7049.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8610.xml"/>
<references title='Normative References'> <reference anchor="IEEE754" target ="https://ieeexplore.ieee.org/documen
t/8766229">
<reference anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'> <front>
<front> <title>IEEE Standard for Floating-Point Arithmetic</title>
<title>Concise Binary Object Representation (CBOR)</title> <author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></ <organization>IEEE</organization>
author> </author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></ <date/>
author> </front>
<date year='2013' month='October' /> <seriesInfo name="IEEE" value="754-2019"/>
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format wh <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
ose design goals include the possibility of extremely small code size, fairly sm </reference>
all message size, and extensibility without the need for version negotiation. T
hese design goals make it different from earlier binary serializations such as A
SN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>
<reference anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'>
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Expre
ss Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization />
</author>
<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></au
thor>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<date year='2019' month='June' />
<abstract><t>This document proposes a notational convention to express Concise B
inary Object Representation (CBOR) data structures (RFC 7049). Its main goal is
to provide an easy and unambiguous way to express structures for protocol messa
ges 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="IEEE754" >
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author >
<organization>IEEE</organization>
</author>
<date />
</front>
<seriesInfo name="IEEE Std" value="754-2008"/>
</reference>
<reference anchor="TypedArrayES6" target="http://www.ecma-international.org/ecma
-262/6.0/#sec-typedarray-objects">
<front>
<title>22.2 TypedArray Objects</title>
<author >
<organization></organization>
</author>
<date year="2015" month="June"/>
</front>
<seriesInfo name="in: ECMA-262 6th Edition," value="The ECMAScript 2015 Langua
ge Specification"/>
</reference>
<reference anchor="C" >
<front>
<title>Information technology — Programming languages — C</title>
<author >
<organization></organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="ISO/IEC" value="9899"/>
</reference>
<reference anchor="Cplusplus" >
<front>
<title>Programming languages — C++</title>
<author >
<organization></organization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="ISO/IEC" value="14882"/>
</reference>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <reference anchor="ECMA-ES10"
<front> target="https://www.ecma-international.org/ecma-262/10.0/index.html">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <front>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <title>ECMAScript 2019 Language Specification</title>
author> <author>
<date year='1997' month='March' /> <organization>ECMA International
<abstract><t>In many standards track documents several words are used to signify </organization>
the requirements in the specification. These words are often capitalized. This </author>
document defines these words as they should be interpreted in IETF documents. <date year="2019" month="June"/>
This document specifies an Internet Best Current Practices for the Internet Comm </front>
unity, and requests discussion and suggestions for improvements.</t></abstract> <refcontent>Standard ECMA-262 10th Edition</refcontent>
</front> </reference>
<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'> <reference anchor="C">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <title>Information technology — Programming languages — C</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth <seriesInfo name="ISO/IEC" value="9899:2018, Fourth Edition"/>
or> <author>
<date year='2017' month='May' /> <organization>International Organization for Standardization
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s </organization>
pecifications. This document aims to reduce the ambiguity by clarifying that on </author>
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs <date month="June" year="2018"/>
tract> </front>
</front> </reference>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references> <reference anchor="CPlusPlus">
<front>
<title>Programming languages — C++</title>
<seriesInfo name="ISO/IEC" value="14882:2017, Fifth Edition"/>
<author>
<organization>International Organization for Standardization
</organization>
</author>
<date month="December" year="2017"/>
</front>
</reference>
<references title='Informative References'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<reference anchor="TypedArray" target="https://web.archive.org/web/2011020702441 </references>
3/http://www.khronos.org/registry/typedarray/specs/latest/">
<front>
<title>Typed Array Specification</title>
<author initials="V." surname="Vukicevic" fullname="Vladimir Vukicevic">
<organization>Mozilla Corporation</organization>
</author>
<author initials="K." surname="Russell" fullname="Kenneth Russell">
<organization>Google, Inc.</organization>
</author>
<date year="2011" month="February" day="02"/>
</front>
</reference>
<reference anchor="ArrayBuffer" target="https://developer.mozilla.org/en-US/docs
/Web/JavaScript/Typed_arrays">
<front>
<title>JavaScript typed arrays</title>
<author >
<organization>Mozilla Developer Network</organization>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="RowColMajor" target="https://en.wikipedia.org/w/index.php?tit
le=Row-_and_column-major_order&amp;oldid=917905325">
<front>
<title>Row- and column-major order</title>
<author >
<organization>Wikipedia</organization>
</author>
<date year="2019" month="September" day="26"/>
</front>
</reference>
</references> <references>
<name>Informative References</name>
<section numbered="no" anchor="contributors" title="Contributors"> <reference anchor="TypedArray" target="https://web.archive.org/web/20110
207024413/http://www.khronos.org/registry/typedarray/specs/latest/">
<front>
<title>Typed Array Specification</title>
<author initials="V." surname="Vukicevic" fullname="Vladimir Vukicev
ic">
<organization>Mozilla Corporation</organization>
</author>
<author initials="K." surname="Russell" fullname="Kenneth Russell">
<organization>Google, Inc.</organization>
</author>
<date year="2011" month="February"/>
</front>
</reference>
<t>The initial draft for this specification was written by Johnathan <reference anchor="ArrayBuffer" target="https://developer.mozilla.org/en
Roatch (roatch@gmail.com). Many thanks for getting this ball rolling.</t> -US/docs/Web/JavaScript/Typed_arrays">
<front>
<title>JavaScript typed arrays</title>
<author>
<organization>Mozilla Developer Network</organization>
</author>
<date month="June" year="2010"/>
</front>
</reference>
<t>Glenn Engel suggested the tags for multi-dimensional arrays and <reference anchor="RowColMajor" target="https://en.wikipedia.org/w/index
homogeneous arrays.</t> .php?title=Row-_and_column-major_order&amp;oldid=917905325">
<front>
<title>Row- and column-major order</title>
<author>
<organization>Wikipedia</organization>
</author>
<date year="2019" month="September"/>
</front>
</reference>
</section> </references>
<section numbered="no" anchor="acknowledgements" title="Acknowledgements"> </references>
<t>Jim Schaad provided helpful comments and reminded us that column-major order <section numbered="false" anchor="acknowledgements" toc="default">
still is in use. Jeffrey Yaskin helped improve the definition of <name>Acknowledgements</name>
homogeneous arrays. <t>Jim Schaad provided helpful comments and reminded us that
IANA helped correct an error in a previous version. column-major order still is in use. Jeffrey Yaskin helped improve the
Francesca Palombini acted as a shepherd, and Alexey Melnikov as definition of homogeneous arrays. IANA helped correct an error in a
responsible area director. previous draft version. Francesca Palombini acted as Shepherd, and
Elwyn Davies as Gen-ART reviewer and IESG members Martin Vigoureux, Alexey Melnikov as responsible Area Director. Elwyn Davies as Gen-ART
Adam Roach, Roman Danyliw, and Benjamin Kaduk helped finding further reviewer and IESG members Martin Vigoureux, Adam Roach, Roman Danyliw,
improvements of the text; thanks also to the other reviewers.</t> and Benjamin Kaduk helped in finding further improvements to the text;
thanks also to the other reviewers.</t>
<!-- LocalWords: CBOR extensibility IANA uint sint IEEE endian </section>
-->
<!-- LocalWords: signedness endianness
-->
</section> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <t>The initial draft version of this
specification was written by Johnathan Roatch &lt;roatch@gmail.com&gt;.
Many thanks for getting this ball rolling.</t>
<t>Glenn Engel suggested the tags for multi-dimensional arrays and
homogeneous arrays.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAOuSnF0AA9087XIbN5L/8RRYuupCOiRFUpREybFvZVlOnPXXWXJSe0nK
BocgOdFwhhnMSGZkbd1D3APsj3uSvTe5J7n+AGYwQ4qyclVXdafarIcDoIFu
9Dca0+l0RBZmkT6SJ0kchEbLp2Gs0pV8M/5VB5l8p5epNjrOVBYmsWyePH3z
riXP1czIaZLK89VST+RxmqqVEWo8TvUlQII+MnNdMuqiuMskCWK1gNkmqZpm
nVBn004wTtIOtXdwUCdSmTaZeCAn8HAkB73+Yad32BnsCWEyFU8+qCiJoSFL
cy1EuEzp0WSDXu+wNxAXenWVpJMj+SLOdBrrrPMM5xKByo6kySZCLMMj+VOW
BG1pkjRL9dTA02rBD0GyWKogo4cF4G1+EULl2TxJj4SUHfhPyjA2gGVXPk3S
hYpjesdonajUZDqutCTp7Ei+j8NLnZow+8//yOTTVANoef6vL6iDgTVoWNzb
xGRTFczl7m5vOOxRWxBmqyM7gF8kE5jnWWcw2t07tG/yOEuh17caJ13Ry+Wc
aPT18LAzHPQ7g/6os797OOhTo16oMDqSgRonf85+D7uwQnqfJsgIehJmSSpE
jDhksGxE/N3zk4Pe8BAGwW7x79F+vwe/J5MIfr84PT092BseEZzOkZwu6cny
FrbKM9w8lU6IK55HCcCOZ523SRhnwEFhNl/oLAxoWElwAmf/taREYEw3nYba
hPE0cT3tPLD5sJYOMMSIGpiRpioyGn4TzxLLnp7t88hMpTPcgXmWLY92dq6u
rro6WKhOSCxErK8iJNMOvR7sD3b2u72dB0YHHeJvZt+EZMb4mD+xKxsMugNv
Zite5hY8ZCOMj+TpyatjnEvuZ3N5CrsCy2g3jmTjfK6p8SxIw2WGErInX6p4
lquZlmdLHYTTMKBVNzz8sVuntw9vTo4qmwMT006DfGc6mMdJlMxW8r/+7d/l
2zSZpWqxgI2SkZ3AUMtJFfDotg05e7Pz4vTkSB6ODpFbT5ZRbvC/ygq2TPP1
19WJDu6aqD8cjQYC9ILDivm3JH1lZk9/VQm3lQ1J/n/oyh/yizDQl5ZpSy3w
Q6Qm4SJMN3QgDn6V/B5GkQKVmy6TtJxvbY6/dOW73BgdRbUZ/qJj0GzztVYC
/22SzCLdho0NulXq9Tu9AfxvjecNMr0ed1UazIFgxOnweweH9Aa9g95gOOzv
7njicTFPkzgx1DPVsxB02GqnFIUdA8Q0O6zKd2A+IvHTfDrV6brI4fQTfamj
ZKnT7oKpw+IWd96f7YDVMDs/wnq+V5eKmX6Hdu6DNSvejpZdqpanQofdu7WM
26Nnbl3ytc7AsFyg8kuuTpLolfo1uQUZHXevwosQpg8Zj6udMJ7oT93lfPnP
tNDHAKPzAa1ZkET5Iu4sENoHMFw6/ackmoSTx4f9g8Pe3i7YPQ89HCZhmPSH
SRpWRZFt5v7diP7oFgpC0+kA8DHsJVhAIVDNfLlX0EabINFItGRopMKlKMFC
KK/mCQCZgMzOYjlLQBMDgwdRPtEyg1mWiTHhOIzA2MlkKvWnDA1etJJmoYC7
0eZJE/4OPD1VYerey4U2BlUeNyFVYKSOC1BXYFSSPMMpRKw1Wx4yw7DoWM+S
LCQEuoyrxUkCu+Vo+uVCXYAeymHlsKhsDlhV4WcJoDQNYy2ViPPFGJgEOt7u
/mAr9APlFRB1YM1GXoH84r/AXEJNWMurqASwyKMs7IA+wYmpCRGdJ4tkpmOd
5MYC74ISzIDyAo0WMNuEgAJa4NfoVMeBLhGjhUHTi+PXx9KKL28lIapFiQMj
OOkycyxCMPfgdYFvlSaTPKAx9u/6QYhvb8Rj7+/+XHR9bX2Nm5sWbElyGQLb
CLdissjBHIwEbQqsGxaRp4AtErTYcQVY/ZaH5DYxukrAZB01S5EPTDAHH6gr
HMdaLJFrx8rA7hidIXiCiTtoKlulkDQzsFZioXEtoVnA4oDNdazGkbZsMkFz
hmteAyZNvgTFn8FKLkHuVFzZiBXQ+p0OYOHRCqYF7l4sI41ILGh7tjCUnMPq
UhgLSnxCjAAEzuQ4AVMRxrQYUKMSjO1yHgaGfNw8Rla+vi4t5M0NsVgYCxzg
KVTjW8jKEPCkbm4qNILRQZLC9MuEKUFYLNxuGxju2YSbG0D6LEQmhTmBUypY
LsA6B/AMcg/6g1YAu6oW6PgaR9o2jky1CI0sEAecS4ax27HAt8TfnnqQpB4A
UqTjWTZfwdpjpyhQIaFXbiXc0pGWBjJ3jmoB1iNBpyXSqEvYbwggtEhg/Fyr
CU0DnAFKDFfALEAsSVA1EwVnQSAEFYUGoBbiWnJnqWUIr1SjhZ14KofYMMC5
xToh6/pGbtA34ov1jSB1I/+H6oZ4rKZpXieZZkyQJMtl5FiO3uEyUnQsyl10
TINgQARw9wyojRSlUU5R5BPa9mCeJAZ34VKlIfAQUER3Z902A0FmRb2UJQKl
F+I3sC/QA0g+QQRp45rIgii4oHDzmH+02PiUmzMOwbVHn8HubhtMLdhAjRzK
2sNhy+wEZKzKVkhmB2iaCTR04AxmyEoAepGk2iopRB+1PuCVgOZVBpcOWPha
VThMSVsC6kAQIhsv1lipwQnj+ljHTHk0EWPoMoEGWCJvdWNJGw2at4FrABnU
wJDgwsPmwtoKfkc+BrOfEqpC0eQdWD/8BuUOUXgSoZ3FroWhdXvZZufAdUPl
BntjTe4VaLC57V9OV6CrACkiIRCYuwYwKTCXOKdlcpBT2i5cvLlBI1f8CfHN
n+D/0YBdaPAmwMsCvF+9PztvtPlf+foNPb87/Zf3L96dPsPns++OX74sHoTt
cfbdm/cvn5VP5ciTN69enb5+RoMB6vFfG8RNovHm7fmLN6+PXzYKHikECpGD
rR5bewhbkfGuAKlBVY+Z2GjdBv3+Iaha+Sf4gc+oaGWn80T8b6LVgLey8kqU
iMo/gqjwEZVPT97+4+/9IeBZoml/jPoHQ/gBshfzbEkM7iP/BMZZCVAvWpFW
R0EL1DLMQJOTpjTz5CqWKB7ENqingElkY7zKdKMQUbQxGUrPlQxykyUL9HBA
hoCHyVUwqziJVwvSrY0kyHTW6IofSehATQCGLvMhyb9cRgr1QrtGCJiK1Wuc
WMGeqgV4obD0aZosnKCshdHyBAhxAhRosr+NbRBU94dfGdkbx3EsxuyTgUML
+jJCu1wE6eCBgfr7FGgMplAX4CwYC6kM9Fnj54c/P2xIysmx6YDVJzEqCd+r
ZpqRzagQTVlFHlli1fe+DeoVfClw/fKU9KbVkGAh0Oo6wEGkIHYIAAypNTuP
Yw9TGFVR6DZtTTL15/iJNPsQ4B7Lxpqlo1UXYNAbYKVujS2yKLKO1UQG4nNr
KTK3SFSuOs8QV1JhzhQIAkDBUl3zIgD0Wqv2j3y8BURDEfVoeSQGER6HM8mG
q8GCBXsKQWP5zqlEWAGEowgUlg7wTCZ8xwr5W07DFOxJ89XZU35s1ZdofZAZ
GRGcTolIow26DdTL20C1neUFrzUi78fLKnsausgumLUYw/cWEc11d8W6ymzz
7H6xXYD+guyH40trJp3DbQWkumbLg2B4kYqcIhSF8ar2NSTZdgbWCZ4hJhKB
Q4ThRNNjxwHKHshsgjs2XpWj0Huw2+ciDBqARqOwg+hOApKkMRhr6QuAdWK9
uS3ZfTqVpEe+o9a6gTyfg3MlSQarQ3ETnJcKnvhR4SsVTCObOTy22mLtPXim
X1FssnTek6GexGWU4j3YG7ptmdpEslhSItnN3yz2FuhwhftvXTXYuOfO9y72
yyLQFuwM4ShygzHuqrE9BwiGOIU4FkXqSIjP8iW1SKD6Z4moAeU+08rpgdZJ
5PwMfd1fz/Ydub70wKj196t9+7YvvOe+9MB9dwfVvgPbd3dg+9ID990fVvvu
2r7wnvvSg13DYAR9r4/kA4c3Z68aFtlLFeXaNG6E+A4Ixxv12jMJxLX+9nJ6
BygHVvg1+cmyiaYDPVwFQUPbYmZ3O1+DF69xkgdSeCBlCZIp0bIyixlUi14F
dCkrooi1nUKnMZ7LXnDh9XVnuvSiV7B/ko8BkDUq3ixqAfZlKCzB5BG4xUQJ
Mw+XlHfxQmKwlBBWpdHKCXlFK7rYNdWdQuYxuGXfkSfFsBlm0yGZT1h1aSBk
M+ZsJqsAyh+2JBFNstWwIRBpQYiPbIRcZryK/BQlF5zb3cXUEPQCH8p6MGAT
JoT3YFj2oqDFBn4V4OBBpGjzsQ2CtRAoOoaFah0Xu41s4YRektBzmMBMgSGb
4yjWJ622jRDKiI79QLc9gEWeWrm2DM1oEFVwVZSBCaerWg4DkzOpy0S5HR5r
VEage5OAQnP2EeDnFWpgULX6ktIApJwpfC5PXwpPjpi4jI2P8MDVLo07gYjC
ukYHXYkhimz2Pg17+Kb3ae+gVfr3NERSdAm7KvMlUjGRe+R5gisVTcwRuIG9
fu/nD9OfP5ifP+ifP0RRmz3sTIURs/v1NXcmRv8sn+MP0BHvgcnu/4e6h+YE
CBnbUJTCjLHutWW/DXrxLghTfoKeLOu02TCWfpbKdgsEU4HAQ+Chrl4czJrS
QQi6AqGULjek4n9tXANwAUE4dskDp4gsOzavr63iBV+8uw4BNTNvjVPMT4ud
dUYeWE+OHEs5qUOVfV4oPHJzVphSgTFkGslpKpJTmN+CgTGqE3C1g5zTTuOV
+Dh4+LA5lV8DJq2Psgmr/9iX33wjy3fkUoGDQj76phAFvNjm6yQLA5vz6U1J
QDFLlfLxAKaqNviWIeZvfNexXebqwjHq2OYQOrV8b6fbYg01t95X3ROl6VB9
eZQp/H0/9ScoY5I5jaUnFLuFQUhZ2zGoZlIaeOjgpNruqd0EXI1g34vwrfYg
LNZczhe8FWMt0DvKs3XobdLzuJVtfyLr5JFTlYbGWgux7tIX+KHLGWIOtHAy
oetliA41KizggCPxEUHbNT95Uu45KInnlo/Judlhz4YVWF0do3pK9QSMHWxq
V7zB+NwyaSENnuGyNqTMkGHkYaxwYtCeB/MusTbqTGKoK8xgWdZh2FXBdCA5
QwYLdTkQzHrhJG2K8HFBLgeMOen0gmdECqaXmLg8Jt8ew1QVUbqJcb1zIWJ9
IewUkn3g1F+BI9kjB8HG5M7r9RnUhnu065FagO/gJ7WJbbz4rZo64iwjWwD8
eabppOcffz/o9rv9vmx+PE/e4wpPEPLHlo185OnZ/j3OCx7xYo3JF0uKn1wm
km2mUxauCiPaEIGSCbXoTqEXWC3rDDGtx9ptFPWEQICVvU0pwAwBsCD0b9uj
JjTejTQBbgSBWS7hZwPnueVUGaBC3xnnEtBpuCU4qYRFlXiEfdJUw6rwdDOh
tL01RkUus/lx+lE+fiz7rWq6tnDJMOcKyjQ0c+cuuaiKnGhn0RxAJvxH85H8
AKQgL+l3nSbWSQaeFW7RVzQldi+Iit6TDbH43RwPPjwvZTTChR3utUDHLFQY
UxYeX2GSF1RL4qd0mEHQ6xLH5YkEV2VgqVkl2q8cLa4lzt1RSUaBqXe+wUyC
Xhprh1drxxzHRQ+rZFFbjsnjp3xRNdMkXLahPFGhXhUvPfScyHEeRpNNpyul
Q1+6Qo7069ZHmHzccScwiMh3XqqjQMFhwCrS2DAMZsNEQu1MJRE2s485hk3p
NAawllJpC32pY8qlQrNfSTNJNBtHnAcTOrcQu5JMqOQVjjcdexPssJrIKE5j
nUyS8kBNB7or5lOuJnCrD6lVnpgjATk9xYNL9tGiGOH8pts2D3Or9qD3t5xO
vqA/BGew7x6MLLlS6QSP5+NKQwvTUJG2AGDhDpECTePc5Ax/OF17y2L4MGYN
GFqSzOhoaokliHD+ppF/R6bZOn2cg9w6GTpBFzFmyTmwrSZAldXkFoY3GSab
YGNI1lRaRtbjVT0HjIqGzkqdFOC88YwPONLkyi+AKQM7HLFeIIOlBWXlDsUy
Dx48oJIa7vWGymgEqJwjcSSHPSGeYcL1RaYX+MJutp8ybhFyeJJqD1hx9lv6
CentertMPm5IjbFCDzI206iWC9wAioVv43rlSyoeEHrT0rljZZv5DQBZUxst
X9lYzAu+9jiJzlYNBxP4rIOcch1W8bOxIN8GHPZSiJAD3bGsnhA3h7McZ2/W
thGz2tfX+lOHmA4A3NzQUQzVFGlQUGWpikLab1ISrCpPihijvZ5iJ65UWVEN
wK4SZTOUcFPX4KJmJYfT9wLwLSz5b3/7m+D03AfQJj8Nfvlp9xf5WF4Dra8H
bdyL0U0bgradhxIQhpjxIdbFXcP7/n5bDvb2b9ri5pEQ36AVHfaeyAe36kCY
EGu4RgMbBz7g981Bi0u7XEP9vZS9gW1wPAdtsg/q75mbpOi5W++525IDwL3W
k5a7v4fLtclJ1gwWzDCwYLwopNkvFwQT9WBRlQVV2oZ+27DaNvLbRl88rt/z
2/r7fmO/V2mEbWnRzmKg7bGki7bXDVvBgCfEKchaGGtXGLpfcHSpMDfycV5E
alsYMqTz/1/zmKuxyJFQXomA3RB219pFvYStoXOeRoAVenERcelPCnNdbXDs
lksd28ylgFWnGYsoUuX/GK+O9itT7den2syGwEr1xpKfgAfrjaMvG9nvrTV6
rNg//GJe7N/FjFaz1RgCuRLN3wnbyVdeISn5lZs5zpTHsM46uLwAeabwn+Fg
kUwbdGmgtiP13nBmmk1faNxwriOxkzsOXObpMrGnSusVMnhWC1PAupIZGpFa
1Qtpdjozb7AfUFmBQwWA2gJDrw6nQEBQ/r3IRfR7wx4FymEU5VTA5HKj3l4M
yKuwDgSOqLsQ1tHPSG7WD9cnX2B1hdxud9mfvdvwApzmupNUEW3E4A7hbkuf
wGUl8v9bgf/jMr1VV9xD4Af3FXiOVTftFJ3c1T3B9bCs9In7X+ATCxuZk3Fy
RWM2iNkUXjaVrEVo3NASNrDDVGR2WxRqvTiDSToqEVsrzxD18gw//OVqiqI2
18aEG2IgUQRS2Tw3Rbmbi1q2QnUg/FDTTuGKPf2APbyt6sPhhGF1oQ+F0QsF
RA7ISG8sDD+OTEKZ4UCnGBdTctK0Rb0mF1pAsyXxDHOw5OGW13HsaaI7uwxS
DRpQxHTD5pZ6C7dCW/XsVTES8yF41GmCA2CXuoP1/kgGgliENSJwG2sx4HwI
rMs99rZVVLIaSHXPaOCSa5vkwgxv7WWkETsPyJ5iryGIinicJJFWTLeTr7+u
lk4V7p9VqNhZ4v+RjEF8gMEBXWJs89U0WXr//SeoJdYzO+c1Z4q0SU2NPt8r
WviKpH09LF/zTThPs/jYWd3y3RrCFsk1r9YbjI4t174b34t0Pilllbmu41NZ
um/pQ/ymXUk/xU1EMq6yeCTwSlTG1u6RuIFtSR6Br5DIxapC0Gum6C7EWvax
M7ypkFY4K7Rugfjt2uuSsBWSesbogdz1YKwD3g5hQBA6w1u2pH+vPQEFHZog
N2QF/WzpGV86KA/t+fCBrxONw1nHnkLU4mSUe6P1AjNayPTBXOH1IPCMiio6
z6OjvO4V3vWY5hFokfLkxtbKC3v3gc82YA2xLkOSopa8LAWu5tvtQZkoSyww
zUhVz3TdQ26o29+obqtZY3dcz4nS30nHBfM8vrBI2wIDLL/q0LkdmjYq83c3
AOyC6aYSVyJRM2L5K3iL7DBbQ3EFRhEHiPptjjB2DmBxyQXW+9YdTGB6dj2p
5R0abcvUFdsI9NfpNKLUC54lJQt7dwpWBHuG72gTiwtFQAmtll7lNenRys0B
gCLtScKlCiOiH+eFQcIV8gEeVdARGVOaKsMzR10F3uqUbg24zLelHl/AKqME
Sq7iIUmZMtKX5GIAnY7RKjKZNufEAbNqypOPLnLDSxzjeag9h+QLMIZPW/Bs
hvisCBbsRroLY9XIhG5Kgct08uzZS9pfLB4yFVEsTkeNZX7qe33dwdvUeJEG
ebwY6hceXV8DJrYbRVip5ovqsKwjUqQECxi0w0eIj+WD/e7+sIm3+lrudX8f
LDm37FVbdgdFy361ZX9YtBxUW0Yde8Bom0f1ySI38LA+mWs56NUnK1r6ZYsp
MToYVF+XGB3sVltKjA6G1ZYSowNHhUfFae4Rvd+vz1Is66A+S9Eyqs9StHjo
0wlfuehRr9ZUrnrUrzWVyx4N6gAHo6Jtd20yt47RcG2yomlvbbKiaX99sqLN
UcOzWt+Q3nnCHYb9pnXpC/30DfzXlpVOveZP5ctfvL4dX++tD8QwtTbUWVIn
Lc6EvivFpZRNMokoNmg/WXjpqtKJu0ZE3nGt5ph6YLzh13q5Sj8W1DF+0KLD
ATpKtbNzYu2mqb07VbVKhcoDTdw8p6tVzJvsBYmwrD2wXuo0R4dKYkLGmcBa
otpgAQzCsqsmtz/AoMizdI36Osi2Thr2ZltzMOx2B3t7LS+ZyIkMOyenStyt
mxpsioGwfsVlKhgDC1xi1NvttqjODB02+VkWAafvM32WZ0XY80V/WG6Fpa9Y
2+pVxHgAWWH6BuJugHt3AcTkvl8ZtgU8Ady/C+Du4H4AD+4CuD+8H8DRvWjY
dtUn/k2XKsDDL6FhpWTn9kUiwIPel9DwPgD7X0LD+wAcbANo7s+HB7t3Abwn
Hx5slRRzfz482Cop5v58eLBVUppOM7a2E88HuFVSzB/gw62SYv4AH26VFHN/
PhxtlZRaNdNdHEQAt0pKDeBdHEQAt0pKDeBdHEQAt0pKHeXBaCtEArhVUjbQ
cNv+EMCtkrKBhncC3CopG2h4J8CtkrKJhlsgIsAh82FRw1BWVDyE17dUD7Vl
rXDAY2z0QP4AwA3htQU47HsrrP193hBvbv37bF1T3z/Euc3jr1IZyegr563+
YEv+8Utr4Luhe/qwhdSCF4RikR09csdF3vcEuASpSBQVffEjITZv62fha/Uq
lY+7UQ0VwqTTfnD/RgfgR57pIE/x6xFbHeVzPsvinkGlJ0IsvsFBWe1HRf2s
yrDciQ+wxCRVXGTkHYwtVaroSxYIxVaoypEP0l6PPLeVxBuS1JxgoFLTBSat
1BhdVVvtO7NfFRFENFuUulBY5A0gIkaGspXuEwxhvMy9ann63ICmCrtZnKTo
xx+7YksuDaacNx8y2jwDX3IHSTF5agviObMSJxmQIbzkqzAJ34RymQGT4V1O
LO7zk132uGCSUPZimkfTMIoEZy4svvGkmIOq9uh4MM4pxW8HEDmO376wXxkI
Mv4yCJ1Z8CVnLIDEBIw93MTjFr7U4l2RpYMN3IV6hqtNBYlZpoILnVKaimpJ
abIkkvgpC971uSrr0QjIREf4UT2uAmTSM4f4JwEuDvEyOVrzjSQQvBC/l8SL
ZPhj7hNmglkj5HNZPEsjbkVarFcPw8a+ibGQK/wtR4rwZySwELGavZxMeIWh
KcucS+TlIpzNMzqBtsccSpRV1u7LcVP+lIQ97PXPPPQnnBfZmUYV9V7iEu9W
YFpUteUyIbGijBfezaICkwRbV14Wrsl1wwwRnChR4irL4ya7GSFoTL1IEABu
S5HYN76AdCk/50p9ZflpCTpUgnmDzCsALHfrCjnQFTrjxQdgJkxTsqTaL0dw
0aAtmiOVQRIYppYt7E772Tn8mtEYyC7ECXJaOM6zJK2pLtDSnI7Uk8eNOHF3
ZsI4RALyNyxtxcxaSvkK5QJUHn4NErD6PpmDygWGF+8SlQE/NlP6988z/BZj
F8JhvN7zSsVUwBpfsNKf6Swr8BujXIFIRHxb99tIx7E8BQmKgGVAWZlKCuKW
T0cVaXSx6Ysu4jjAcs5IT2a2DnCt6HoDTb4PF/IMhFlNygzpXEdL3Cb3FU3S
NKlehDa97xhg7SNmsIeociiHAjoDiPK9nk5TvZJ/VQY2myBjLnSBc2mrRae0
J/xBmY2fqqFkDY+kzxIFJHk6TfnOoypvt9jjg654nuLtURMo+VZFVAkeYj67
KKie6yVw6YST58eR/gRrfKWjOLxILvECHX/7yISYDAemVfa6Z5J2xWl0tYrl
M3WJ5+IA7Vsdd47fnVPiRl/ZS44vTs++lQvN5VmvFF7EkT+EswQkK//UFscT
tZDATFjT9S4BkQR48SoKr3hBT3X8qwJyy7+oSX7hcJ+G/DEmq8KEpWLlLDXT
n7JHjgvpq0bW7nLNvlsjsgtdPpQvk0BFP+JnRI4k28HqZ9KI+HQjmm5Dk3/I
niB/imQDFO8yZ3lTiHv/NxPVv2mzVgAA
</rfc> </rfc>
 End of changes. 53 change blocks. 
842 lines changed or deleted 677 lines changed or added

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