<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.8 (Ruby 3.1.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cbor-file-magic-12" number="9277" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <front>

    <title abbrev="cbor-file-magic">On storing CBOR encoded items on stable storage</title> Stable Storage for Items in Concise Binary Object Representation (CBOR)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-file-magic-12"/> name="RFC" value="9277"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>D-28359 Bremen</city>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2022" month="May" day="05"/>
    <area>Internet</area>
    <workgroup>CBOR Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="August"/>
    <area>art</area>
    <workgroup>cbor</workgroup>

<keyword>magic number</keyword>
<keyword>file identification</keyword>

    <abstract>

      <t>This document defines a stored ("file") format for CBOR Concise Binary
   Object Representation (CBOR) data items
that is friendly to common file type recognition systems that recognize file types, such
as the Unix file(1) command.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        cbor Working Group mailing list (<eref target="mailto:cbor@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cbor/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/cbor-wg/cbor-magic-number"/>.</t>
    </note>

  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Since very early in computing, operating systems have sought ways to mark which files could be processed by which programs.
In Unix, everything is a stream of bytes; identifying the contents of a stream of bytes became a heuristic activity.</t>
      <t>For instance, the Unix file(1) command, which has existed since 1973 <xref target="file"/>, target="FILE"/>, has for decades been able to identify many file formats based upon the contents of the file.</t> file for decades.</t>
      <t>Many systems (Linux, macOS, Windows) will select the correct application based upon the file contents, contents if the system can not cannot determine it by other means.
For instance, in classical MacOS, Mac OS, a resource fork was maintained
separately from the file data that included file type information;
this way, the OS ideally never needed to know anything about the file
data contents to determine the media type.</t>
      <t>Many other systems do this by using file extensions.
Many common web Web servers derive the media-type information from file extensions.</t>
      <t>Having a media type associated with the file contents can avoid some
of the brittleness of this approach.
When files become disconnected from their type information, such as when attempting to do forensics on a damaged system, then being able to identify the type of information that is stored in a file can become very important.</t>
      <t>A
      <t>  A common way to identify the type of a file from its contents is to
  place a "magic number" at the start of the file contents <xref target="MAGIC"/>.
It is noted that in  In
  the media type registration template <xref target="RFC6838"/>, a
  magic number is asked for, if available, as is a file extension.</t> extension.
</t>

      <t>A challenge for the file(1) command is often that it can be confused
by recognizing the overall encoding vs. but not the content. content being encoded.
For instance, an Android "apk" APK (as used to transfer and store an application) may be
identified as a ZIP file. Additionally, both OpenOffice and MSOffice files are ZIP files
of XML files, and files; the identification may also be identified stop at identifying them as a ZIP file.</t> files.
</t>
      <t>As CBOR becomes a more and more common encoding for a wide variety of artifacts, identifying them as just "CBOR" is probably not sufficient.
This document provides a way to encode a magic number into the beginning of a CBOR format file.
As a CBOR format may use a single CBOR data item or a CBOR sequence of
data items <xref target="RFC8742"/>,
two possible methods of enveloping data are presented; a CBOR Protocol designer will specify one.
(A CBOR Protocol is a specification which that uses CBOR as its encoding.)</t>
      <t>This document also gives advice to designers of CBOR Protocols on
choosing one of these mechanisms for identifying their contents.
This advice is informative.</t>

      <t>A third method is also proposed by which this a CBOR format prepended tag is used prepended to identify non-CBOR files.
This third
Further information on this method has been placed appears in <xref target="headers"/> because it is not
about identifying media types containing CBOR-encoded data items.
This includes a simple way to derive a magic number to for
content-formats as defined by in <xref target="RFC7252"/>, even if the file is
not in CBOR form.</t> form.
</t>
      <t>Examples of CBOR Protocols currently under development include Concise
Software Identification Tags (CoSWID, <xref target="I-D.ietf-sacm-coswid"/>) target="I-D.ietf-sacm-coswid"/> and
Entity Attestation Tokens (EAT, <xref target="I-D.ietf-rats-eat"/>).
COSE target="I-D.ietf-rats-eat"/>.
CBOR Object Signing and Encryption (COSE) itself <xref target="RFC8152"/> is considered infrastructure.
The encoding of public keys in CBOR as <em>C509</em> as described in <xref target="I-D.ietf-cose-cbor-encoded-cert"/> as <em>C509</em> would benefit from being an identified CBOR Protocol.</t>
      <t>A

<!-- [rfced] Text updated as shown below based on your reply.  We used "confounds" instead of "confuses".  Please let us know if any changes are desired.

Maybe:
A major inspiration for this document is observing the disarray in
certain ASN.1 based systems where most files are PEM encoded;
these files are all identified by the
extension "pem", which confounds public keys, private keys,
certificate requests, and S/MIME content.

Maybe confound or commingle?
-->

      <t>A major inspiration for this document is observing the disarray in
certain ASN.1-based systems where most files are Privacy-Enhanced Mail (PEM) encoded;
these files are then all identified by the
extension "pem", confusing which confounds public keys, private keys,
certificate requests, and S/MIME content.</t>
      <t>While the envelopes defined in this specification add information to how data conforming to CBOR Protocols are stored in files, there is no requirement that either type of envelope be transferred on the wire.
However, there are some protocols which that may benefit from having such a magic number on the wire if they are presently using a different (legacy) encoding scheme.
The presence of the identifiable magic sequence can be used to signal
that a CBOR Protocol is being used as opposed to a legacy scheme.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>Byte is a synonym for octet.
The term "byte string" refers to the data item defined in <xref target="STD94"/>.</t> target="RFC8949"/>.</t>
        <t>The term "file" is understood to stand in a general way for a stored
representation that is somewhat detached from the original context of
usage of that representation; its usage in this document encompasses
similar units of storage that may have different identification
schemes such as partitions or media blocks.</t>
        <t>The term "diagnostic notation" refers to the human-readable notation
for CBOR data items defined in <xref target="RFC8949" section="8" sectionFormat="of" target="STD94"/> sectionFormat="of"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>.</t>
        <t>The term CDDL "CDDL" (Concise Data Definition Language) refers to the
language defined in <xref target="RFC8610"/>.</t>
        <t>The function TN(ct) is defined in <xref target="ct-tags"/>.</t>
      </section>
      <section anchor="requirements-for-a-magic-number">
        <name>Requirements for a Magic Number</name>
        <t>A
        <t>Ideally, a magic number is ideally a fingerprint that is unique to a specific CBOR protocol, Protocol, is present in the first few (small multiple of 4) bytes of the file,
which file and does not change when the contents change, and does not depend upon the length of the file.</t>
        <t>Less ideal solutions have a pattern that needs to be matched, but in which some bytes need to be ignored.
While the Unix file(1) command can be told to ignore certain bytes, this can lead to ambiguities.</t>
      </section>
    </section>
    <section anchor="protocol">
      <name>Protocol</name>
      <t>This Section section presents two enveloping methods.
Both use CBOR Tags tags in a way that results in a deterministic first 8 to 12 bytes.
Which one is to be used
is up to the CBOR
The Protocol designer determines which one to determine; use; see <xref target="advice"/> for
some guidance.</t>

      <section anchor="spectag">
        <name>The CBOR Protocol Specific CBOR-Protocol-Specific Tag</name>
        <t>In both enveloping methods,
CBOR Protocol designers need to obtain a CBOR tag for each kind of object that they might store in files.
As there are more than 4 billion available 4-byte tags, there should be little issue in allocating a few to each available CBOR Protocol.</t>
        <t>The IANA policy for 4-byte CBOR Tags tags is First Come First Served, Served <xref target="RFC8126" format="default"/> so all that is required is only a simple interaction (e.g., via web Web or email) with IANA, having filled IANA is required.  The interaction includes filling in the small template provided in <xref target="RFC8949" section="9.2" sectionFormat="of" target="STD94"/>. sectionFormat="of"/>.
In the template, it is suggested to include a reference to this
specification (RFC XXXX) 9277) alongside the Description of
semantics. <cref anchor="XXXX">(Note to RFC Editor: Please replace all occurrences of "RFC
XXXX" with the RFC number of the present specification and remove
this note.)</cref></t>
semantics is suggested.</t>
        <t>Allocation of the CBOR tag needs to be initiated by the designer of the CBOR
Protocol, who can provide a proposed tag number.
In order to be in the four-byte 4-byte range, and so that there are no
leading zero bytes in the four-byte 4-byte encoding of the tag number, the
value needs to be in the range 0x01000000 (decimal
16777216) to 0xFFFFFFFF (decimal 4294967295) inclusive.
It is further suggested to avoid values that have an embedded zero byte in
the four 4 bytes of their binary representation (such as 0x12003456), as
these may confuse implementations that treat the magic number as a C string.</t>

        <t>The use of a sequence of four US-ASCII ASCII <xref target="RFC20"/> target="RFC0020"/> codes which are mnemonic to the
protocol is encouraged, but not required (there may be reasons to
encode other information into the tag; see <xref target="ct-tags"/> for an example).
For instance, <xref target="openswan"/> uses "OPSN" "OPSN", which translates to the tag
number 1330664270 registered for it.</t>
        <t>For

        <t>In <xref target="IANA.CORE-PARAMETERS"/>, the Constrained Application Protocol (CoAP) defines the "CoAP Content-Formats" registry to assign Content-Format Numbers (<xref
section="12.3" sectionFormat="of" target="RFC7252"/>) to Content Types in a specific Content Coding.
For CBOR data items that form a representation that is already described by such a CoAP Content-Format Number (<xref section="12.3" sectionFormat="of" target="RFC7252"/>,
Registry
<xref section="CoAP Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/>
of <xref target="IANA.core-parameters"/>),
Number, a tag number has pro-actively proactively been allocated
in <xref target="iana-ct-tags"/> (see <xref target="ct-tags"/> for details and examples).</t> examples).
</t>
      </section>

      <section anchor="wrapped">
        <name>Enveloping Method: CBOR Tag Wrapped</name>
        <t>The CBOR Tag Wrapped method is appropriate for use with CBOR protocols Protocols that encode a single CBOR data item.
This data item is enveloped into two nested tags:</t>

        <t>The outer tag is a Self-described self-described CBOR tag, 55799, as
described in <xref section="3.4.6" target="RFC8949" sectionFormat="of" target="STD94"/>.</t> section="3.4.6"/>.</t>
        <t>The tag content of the outer tag is a second CBOR tag whose tag number has
been allocated to describe the specific Protocol involved, as
discussed in <xref target="spectag"/>.
The tag content of this inner tag is the single CBOR data item.</t>
        <t>This method wraps the CBOR data item as CBOR tags usually do.
Applications that need to send the stored CBOR data item across a
constrained network may wish to remove the two tags if the type is
understood from the protocol context, e.g., from a CoAP Content-Format
Option (<xref section="5.10.3" sectionFormat="of" target="RFC7252"/>).
A
Therefore, a CBOR Protocol specification may therefore pick the specific cases
where the CBOR Tag Wrapped enveloping method is to be used.
For instance, it might specify its use for storing the representation
in a local file or for Web access, but not within protocol messages that
already provide the necessary context.</t>
        <section anchor="tag-wrap-example">
          <name>Example</name>
          <t>To construct an example without registering a new tag, we use
the Content-Format number registered in <xref target="RFC8428"/> ID assigned for <tt>application/senml+cbor</tt> (as per Registry (112) <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> target="RFC8428"/>
of <xref target="IANA.core-parameters"/>), the number 112.</t> "CoAP Content-Formats" registry <xref target="IANA.CORE-PARAMETERS"/>).</t>
          <t>Using the technique described in <xref target="ct-tags"/>, this translates into the
tag TN(112) = 1668546929.</t>
          <t>With this tag, the SenML-CBOR pack <tt>[{0: "current", 6: 3, 2: 1.5}]</tt> would be enveloped as follows (in diagnostic notation):</t>
          <sourcecode type="cbor-diag"><![CDATA[
55799(1668546929([{0: "current", 6: 3, 2: 1.5}]))
]]></sourcecode>
          <t>Or in hex:</t>
          <sourcecode type="cbor-pretty"><![CDATA[
d9 d9f7                       # tag(55799)
   da 63740171                # tag(1668546929)
      81                      # array(1)
         a3                   # map(3)
            00                # unsigned(0)
            67                # text(7)
               63757272656e74 # "current"
            06                # unsigned(6)
            03                # unsigned(3)
            02                # unsigned(2)
            f9 3e00           # primitive(15872)
]]></sourcecode>

          <t>At the representation level, the unique fingerprint for <tt>application/senml+cbor</tt> is composed of the 8 bytes d9d9f7da63740171 hex, after which the unadorned CBOR data (81... for the SenML data) is appended.</t>
        </section>
      </section>
      <section anchor="sequences">
        <name>Enveloping Method: Labeled CBOR Sequence</name>
        <t>The Labeled CBOR Sequence method is appropriate for use with CBOR Sequences as described in <xref target="RFC8742"/>.</t>
        <t>This method prepends a newly constructed, separate data item to the
CBOR Sequence, the <em>label</em>.</t>
        <t>The label is a nesting of two tags, similar to but distinct from the
CBOR Tag Wrapped methods, with an inner tag content of a constant byte
string.
The total length of the label is 12 bytes.</t>
        <ol spacing="normal" type="1"><li>The outer tag is the self-described CBOR Sequence tag, 55800.</li>
          <li>The inner tag is a CBOR tag, tag from the First Come First Served space, space that uniquely identifies the CBOR Protocol.
As with the CBOR Tag Wrapped, Wrapped method, the use of a four-byte 4-byte tag is encouraged that encodes without zero bytes.</li> bytes is encouraged.</li>
          <li>The tag content is a three byte 3-byte CBOR byte string containing
0x42_4f_52 ('BOR' in diagnostic notation).</li>
        </ol>
        <t>The outer tag in the label identifies the file as being a CBOR Sequence, Sequence and does so with all
the desirable properties explained in <xref target="RFC8949" section="3.4.6" sectionFormat="of" target="STD94"/>. sectionFormat="of"/>.
Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.</t>
        <t>The inner tag in the label identifies which CBOR Protocol is used, as described above.</t>
        <t>The inner tag content is a constant byte string which that is represented as
0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR encoded CBOR-encoded data item for the three-byte 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t>

        <t>The actual CBOR Protocol data then follow follows as the next data item(s) in the CBOR Sequence, without a need for any further specific tag.
The use of a CBOR Sequence allows the application to trivially remove the first item with the two tags.</t>
        <t>Should this file be reviewed by a human (directly in an
editor,
editor or in a hexdump display), it will include the ASCII characters "CBOR" prominently.
This value is also included simply because the inner nested tag needs to tag something.</t>
        <section anchor="tag-seq-example">
          <name>Example</name>
          <t>To construct an example without registering a new tag, we use the
Content-Format number registered in <xref target="RFC9177"/>
ID 272 as assigned for <tt>application/missing-blocks+cbor-seq</tt> (as per Registry
<xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of
<xref target="IANA.core-parameters"/>), the number 272.</t> "CoAP Content-Formats" registry <xref target="RFC9177"/>.</t>
          <t>Using the technique described in <xref target="ct-tags"/>, this translates into the
tag TN(272) = 1668547090.</t>
          <t>This is a somewhat contrived example, as this is not a media type that
is likely to be committed to storage.
Nonetheless, with this tag, missing blocks list <tt>0, 8, 15</tt> would be
enveloped as (in diagnostic notation):</t>
          <sourcecode type="cbor-diag"><![CDATA[
55800(1668547090('BOR')),
0,
8,
15
]]></sourcecode>
          <t>Or in hex:</t>
          <sourcecode type="cbor-pretty"><![CDATA[
# CBOR sequence with 4 elements
d9 d9f8         # tag(55800)
   da 63740212  # tag(1668547090)
      43        # bytes(3)
         424f52 # "BOR"
00 # unsigned(0)
08 # unsigned(8)
0f # unsigned(15)
]]></sourcecode>
          <t>At the representation level, the unique fingerprint for
<tt>application/missing-blocks+cbor-seq</tt> is composed of the 8 bytes
d9d9f8da63740212 hex, after which the unadorned CBOR sequence
(00... for the missing block list given) is appended.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document provides a way to identify CBOR Protocol objects.
Clearly identifying CBOR contents in files may have a variety of impacts.</t>
      <t>The most obvious is that it may allow malware to identify interesting
stored objects, and then exfiltrate or corrupt them.</t>
      <t>Protective applications (that check data) cannot rely on the
applications they try to protect (that use the data) to make
exactly the same decisions in recognizing file formats.
(This is an instance of a check vs. versus use issue.)
For example, end-point assessment technologies should not solely rely
on the labeling approaches described in this document to decide
whether to inspect a given file.
Similarly, depending on operating systems system configurations and related
properties of the execution environment environment, the labeling might influence
the default application used to process a file in a way that may not
be predicted by a protective application.</t> application.
</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>These IANA considerations are entirely about CBOR Tags, tags in the
registry <xref section="CBOR
"Concise Binary Object Representation (CBOR) Tags" relative="#cbor-tags" sectionFormat="bare" target="IANA.cbor-tags"/> of registry <xref target="IANA.cbor-tags"/>.</t> target="IANA.CBOR-TAGS"/>.</t>
      <t><xref target="cbor-sequence-tag"/> documents the allocation that was done for a
CBOR tag to be used in a CBOR sequence to identify the sequence (an
example for using this tag is found in <xref target="openswan"/>).  <xref target="cbor-labeled-non-cbor-data-tag"/> documents the allocation for a CBOR tag to be used in the CBOR-Labeled Non-CBOR Data Enveloping Method (<xref target="headers"/>, which also shows examples).
<xref target="iana-ct-tags"/> allocates a CBOR tag for each actual or
potential CoAP Content-Format number (examples are in <xref target="ct-tags"/>).</t>
      <section anchor="cbor-sequence-tag">
        <name>Labeled CBOR Sequence Tag</name>
        <t>IANA has allocated tag 55800 as the tag for the Labeled CBOR Sequence
Enveloping Method from the CBOR Tags Registry. "CBOR Tags" registry.
IANA is asked to update has updated this tag registration to point to this document.</t>
        <t>This tag is from the First Come/First Come First Served area.</t>
        <t>The value has been picked to have properties similar to the 55799 tag (<xref section="3.4.6" target="RFC8949" sectionFormat="of" target="STD94"/>).</t> section="3.4.6"/>).</t>
        <t>The hexadecimal representation of the encoded tag head is: is 0xd9_d9_f8.</t>
        <t>This is not valid UTF-8: the first 0xd9 introduces a three-byte 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.</t>

        <t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value.  However, the following 16-bit big-endian value 0xf8.. 0xf8_xx is not a valid second sequence according to <xref target="RFC2781"/>.
On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid.  That next byte is determined by the subsequent encoding, and <xref target="RFC8949" section="3.4.6" sectionFormat="of" target="STD94"/> sectionFormat="of"/> has already determined that no valid CBOR encodings result in valid UTF-16.</t>
        <dl newline="true">
          <dt>Data Item:</dt>
          <dd>
            <t>tagged byte string
<!-- this needs to be updated in the registry -->
            </t>
          </dd>
          <dt>Semantics:</dt>
          <dd>
            <t>indicates that the file contains CBOR Sequences</t>
          </dd>
        </dl>
      </section>
      <section anchor="cbor-labeled-non-cbor-data-tag">
        <name>CBOR-Labeled Non-CBOR Data Tag</name>
        <t>IANA is requested to allocate has allocated tag 55801 as the tag for the CBOR-Labeled Non-CBOR Data
Enveloping Method (<xref target="headers"/>) from the CBOR Tags Registry. "CBOR Tags" registry.
IANA is asked to update updated this tag registration to point to this document.</t>
        <t>This tag is from the First Come/First Come First Served area.</t>
        <t>The value has been picked to have properties similar to the 55799 tag (<xref target="RFC8949" section="3.4.6" sectionFormat="of" target="STD94"/>).</t> sectionFormat="of"/>).</t>
        <t>The hexadecimal representation of the encoded tag head is: is 0xd9_d9_f9.</t>
        <t>This is not valid UTF-8: the first 0xd9 introduces a three-byte 3-byte sequence in UTF-8, but the 0xd9 as the second value is not a valid second byte for UTF-8.</t>
        <t>This is not valid UTF-16: the byte sequence 0xd9d9 (in either endian order) puts this value into the UTF-16 high-half zone, which would signal that this is a 32-bit Unicode value.  However, the following 16-bit big-endian value 0xf9.. 0xf9_xx is not a valid second sequence according to <xref target="RFC2781"/>.
On a little-endian system, it would be necessary to examine the fourth byte to determine if it is valid.  That next byte is determined by the subsequent encoding, and <xref section="3.4.6" target="RFC8949" sectionFormat="of" target="STD94"/> section="3.4.6"/> has already determined that no valid CBOR encodings result in valid UTF-16.</t>
        <dl newline="true">
          <dt>Data Item:</dt>
          <dd>
            <t>tagged byte string
<!-- this needs to be updated in the registry -->
            </t>
          </dd>
          <dt>Semantics:</dt>
          <dd>
            <t>indicates that the file starts with a CBOR-Labeled Non-CBOR Data label.</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-ct-tags">
        <name>CBOR Tags for CoAP Content-Format Numbers</name>

<!-- [IANA] Per the authors, please update the entry for 1668546817-1668612095 on <https://www.iana.org/assignments/cbor-tags> as follows:

OLD: 0x63470101

NEW: 0x63740101
-->
        <t>IANA is requested to allocate allocated the tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374ffff) as follows:</t>
        <dl newline="true">
          <dt>Data Item:</dt>
          <dd>
            <t>byte string or any CBOR data item (see <xref target="ct-tags"/> of RFC XXXX)</t> target="ct-tags"/>)</t>
          </dd>
          <dt>Semantics:</dt>
          <dd>
            <t>the representation of content-format ct &lt; 65025 is indicated by
tag number <br/>
TN(ct) = 0x63470101 0x63740101 + (ct / 255) * 256 + ct % 255</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>RFC XXXX</t> 9277</t>
          </dd>
        </dl>
        <t>The Registry for <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of "CoAP Content-Formats" registry <xref target="IANA.core-parameters"/> has been target="IANA.CORE-PARAMETERS"/> is defined in <xref section="12.3" sectionFormat="of" target="RFC7252"/>.</t>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="STD94" target="I-D.ietf-cose-cbor-encoded-cert" to="C509-CERT"/>
<displayreference target="I-D.ietf-rats-eat" to="EAT"/>
<displayreference target="I-D.ietf-sacm-coswid" to="CoSWID"/>
<displayreference target="RFC0020" to="RFC20"/>
<displayreference target="RFC8949" to="STD94"/>

<references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="STD94" target="https://www.rfc-editor.org/info/rfc8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8742.xml"/>

<!--[rfced] May we update the possibility citations/reference pointing to STD 94 to instead point to RFC 8949?  As there are a number of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different instances referencing specific sections from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, 8949, this seems like best practice for in case more RFCs are added to STD 94.

[authors] That seems to be about a limitation of the current RFCXML format.
We do prefer citing STDs if we can.
We note that the current text under [STD94] unambiguously specifies one RFC,
and errata fixes while keeping full compatibility with the interchange format section references therefore work in draft-ietf-cbor-file-magic-12.html — what caused these to be lost?

[rfced] The links were lost because use of <referencegroup> is recommended, even when there is only 1 RFC 7049.  It does not create associated with a new version of given STD/BCP number.  Currently, an xref cannot link directly to sections when <referencegroup> is used because it will not know which RFC to link to.

While it is not recommended, we have updated the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference> reference the reference and links as desired.
-->

<reference anchor="RFC8742" target="https://www.rfc-editor.org/info/rfc8742"> anchor='RFC8949' target='https://www.rfc-editor.org/info/std94'>
<front>
<title>Concise Binary Object Representation (CBOR) Sequences</title> (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author> initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date month="February" year="2020"/>
            <abstract>
              <t>This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq".  A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.</t>
              <t>Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation.  This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.</t>
            </abstract> year='2020' month='December' />
</front>
<seriesInfo name="RFC" value="8742"/> name='STD' value='94'/>
<seriesInfo name='RFC' value='8949'/>
<seriesInfo name="DOI" value="10.17487/RFC8742"/> name='DOI' value='10.17487/RFC8949'/>
</reference>

<reference anchor="C" target="https://www.iso.org/standard/74528.html">
          <front>
            <title>Information technology — -- Programming languages — -- C</title>
            <author>
              <organization>International Organization for Standardization</organization>
            </author>
            <date year="2018" month="June"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9899:2018, Fourth Edition"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2781.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9177.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

	<reference anchor="file" target="https://en.wikipedia.org/wiki/File_%28command%29"> anchor="FILE" target="https://en.wikipedia.org/w/index.php?title=File_(command)&amp;oldid=1096086462">
          <front>
            <title>file (command)</title>
            <author>
              <organization>Wikipedia</organization>
            </author>
	    <date year="2021" month="January" day="20"/>
          </front>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC20" target="https://www.rfc-editor.org/info/rfc20">
          <front>
            <title>ASCII format for network interchange</title>
            <author fullname="V.G. Cerf" initials="V.G." surname="Cerf">
              <organization/>
            </author>
            <date month="October" year="1969"/> year="2022" month="July" day="2"/>
          </front>
          <seriesInfo name="STD" value="80"/>
          <seriesInfo name="RFC" value="20"/>
          <seriesInfo name="DOI" value="10.17487/RFC0020"/>
        </reference>

        <reference anchor="IANA.core-parameters" anchor="IANA.CORE-PARAMETERS" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="IANA.cbor-tags" anchor="IANA.CBOR-TAGS" target="https://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty">
              <organization/>
            </author>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski">
              <organization/>
            </author>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson">
              <organization/>
            </author>
            <author fullname="A. Rusch" initials="A." surname="Rusch">
              <organization/>
            </author>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8428">
          <front>
            <title>Sensor Measurement Lists (SenML)</title>
            <author fullname="C. Jennings" initials="C." surname="Jennings">
              <organization/>
            </author>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="J. Arkko" initials="J." surname="Arkko">
              <organization/>
            </author>
            <author fullname="A. Keranen" initials="A." surname="Keranen">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8428"/>
          <seriesInfo name="DOI" value="10.17487/RFC8428"/>
        </reference>
        <reference anchor="RFC9177" target="https://www.rfc-editor.org/info/rfc9177">
          <front>
            <title>Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair">
              <organization/>
            </author>
            <author fullname="J. Shallow" initials="J." surname="Shallow">
              <organization/>
            </author>
            <date month="March" year="2022"/>
            <abstract>
              <t>This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</t>
              <t>These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9177"/>
          <seriesInfo name="DOI" value="10.17487/RFC9177"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author>
            <date month="January" year="2013"/>
            <abstract>
              <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>

<reference anchor="X.690"> anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1"/>
        </reference>

        <reference anchor="MAGIC" target="https://www.bell-labs.com/usr/dmr/www/man51.pdf#page=4">
          <front>
            <title>archive (library) file format</title>
            <author initials="D." surname="Ritchie" fullname="Dennis Ritchie">
              <organization/>
            <author>
              <organization>Bell Labs</organization>
            </author>
            <date year="1971" month="November" day="03"/> day="3"/>
          </front>
          <refcontent>in Bell Labs, Unix
	  <refcontent>Unix Programmer's Manual, First Edition: File Formats</refcontent>
        </reference>
        <reference anchor="I-D.ietf-sacm-coswid" target="https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-21.txt">
          <front>
            <title>Concise Software Identification Tags</title>
            <author fullname="Henk Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Jessica Fitzgerald-McKay">
              <organization>National Security Agency</organization>
            </author>
            <author fullname="Charles Schmidt">
              <organization>The MITRE Corporation</organization>
            </author>
            <author fullname="David Waltermire">
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date day="7" month="March" year="2022"/>
            <abstract>
              <t>   ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
   extensible XML-based structure to identify and describe individual
   software components, patches, and installation bundles.  SWID tag
   representations can be too large for devices with network and storage
   constraints.  This document defines a concise representation of SWID
   tags: Concise SWID (CoSWID) tags.  CoSWID supports a similar set of
   semantics and features as SWID tags,

<!--I-D exists as well as new semantics that
   allow CoSWIDs to describe additional types of information, all in a
   more memory efficient format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sacm-coswid-21"/>
        </reference>
        <reference anchor="I-D.ietf-rats-eat" target="https://www.ietf.org/archive/id/draft-ietf-rats-eat-12.txt">
          <front>
            <title>The Entity Attestation Token (EAT)</title>
            <author fullname="Laurence Lundblade">
              <organization>Security Theory LLC</organization>
            </author>
            <author fullname="Giridhar Mandyam">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <author fullname="Jeremy O'Donoghue">
              <organization>Qualcomm Technologies Inc.</organization>
            </author>
            <date day="24" month="February" year="2022"/>
            <abstract>
              <t>   An Entity Attestation Token (EAT) provides an attested claims set
   that describes state and characteristics of an entity, a device like
   a phone, IoT device, network equipment or such.  This claims set is
   used by a relying party, server or service to determine how much it
   wishes to trust the entity.

   An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims.  To a large degree, all this document
   does is extend CWT and JWT.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-eat-12"/>
        </reference>
        <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8152"/>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
        </reference>
        <reference anchor="I-D.ietf-cose-cbor-encoded-cert" target="https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-03.txt">
          <front>
            <title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
            <author fullname="John Preuß Mattsson">
              <organization>Ericsson AB</organization>
            </author>
            <author fullname="Göran Selander">
              <organization>Ericsson AB</organization>
            </author>
            <author fullname="Shahid Raza">
              <organization>RISE AB</organization>
            </author>
            <author fullname="Joel Höglund">
              <organization>RISE AB</organization>
            </author>
            <author fullname="Martin Furuhed">
              <organization>Nexus Group</organization>
            </author>
            <date day="10" month="January" year="2022"/>
            <abstract>
              <t>   This document specifies a CBOR encoding of X.509 certificates.  The
   resulting certificates are called C509 Certificates.  The CBOR
   encoding supports a large subset of RFC 5280 and all certificates
   compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA
   eUICC, and CA/Browser Forum Baseline Requirements profiles.  When
   used to re-encode DER encoded X.509 certificates, the CBOR encoding
   can in many cases reduce the size of RFC 7925 profiled certificates
   with over 50%.  The CBOR encoded structure can alternatively be
   signed directly ("natively signed"), which does not require re-
   encoding for the signature to be verified.  The document also
   specifies C509 COSE headers, a C509 TLS certificate type, and a C509
   file format.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-cert-03"/>
        </reference>
        <reference anchor="RFC2781" target="https://www.rfc-editor.org/info/rfc2781">
          <front>
            <title>UTF-16, an encoding of ISO 10646</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau">
              <organization/>
            </author>
            <date month="February" year="2000"/>
            <abstract>
              <t>This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 6/28/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sacm-coswid.xml"/>

<!--I-D exists as an octet stream for transmission over the Internet, discusses MIME charset naming of 6/28/22-->
<xi:include                                                                    href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-rats-eat.xml"/>

<!--I-D exists as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2781"/>
          <seriesInfo name="DOI" value="10.17487/RFC2781"/>
        </reference> of 6/28/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-ietf-cose-cbor-encoded-cert.xml"/>

</references>

</references>
    <section anchor="advice">
      <name>Advice to Protocol Designer</name>
      <t>This document introduces a choice between wrapping a single CBOR data item into a (pair of) pair of identifying CBOR tags, tags or prepending an identifying encoded CBOR data item (which (which, in turn turn, contains a pair of identifying CBOR tags) to a CBOR Sequence (which might be a single data item).</t>
      <t>Which should a protocol designer use?</t>
      <t>In this discussion, one assumes that there is an object stored in a file, perhaps specified by a system operator in a configuration file.</t>
      <t>For example: a private key used in COSE operations, a public key/certificate in C509 (<xref target="I-D.ietf-cose-cbor-encoded-cert"/>) <xref target="I-D.ietf-cose-cbor-encoded-cert"/> or CBOR format, a recorded sensor reading stored for later transmission, or a COVID-19 vaccination certificate that needs to be displayed in QR code form.</t>
      <t>Both the Labeled CBOR Sequence and the wrapped tag can be trivially removed by an application before sending the CBOR content out on the wire.</t>

      <t>The Labeled CBOR Sequence can be slightly easier to remove as as, in most cases, CBOR parsers will return it as a unit, unit and then return the actual CBOR item, which could be anything at all, all and could include CBOR tags that <em>do</em> need to be sent on the wire.</t>
      <t>On the other hand, having the Labeled CBOR Sequence in the file requires that all programs that expect to examine that file are be able to skip what appears to be a CBOR item with two tags nested around a three-byte 3-byte byte string.
The three byte 3-byte entry is not of the format the program would normally have processed, so it may be a surprise.
On the other hand, CBOR parsers are generally tolerant of tags that appear: many of them will process extra tags, making unknown tags available as meta information.
A program that is not expecting those tags may just ignore those extra tags.</t> them.</t>

      <t>As an example of where there was a problem with previous security systems, "PEM" format certificate files grew to be able to contain multiple certificates by simple concatenation.
<!-- Note that PKCS1 is not an abbreviation any more in standard usage. -->
The PKCS1 format <xref target="RFC8017"/> could also contain a private key object followed by a one or more certificate objects: objects, but only when in PEM format.
Annoyingly, when in binary DER format (<xref target="X.690"/>, which like CBOR is self-delimiting), concatenation of certificates was not compatible with most programs as they did not expect to read more than one item in the file.</t>

      <t>The use of CBOR Tag Wrapped format is easier to retrofit to an existing format with existing and unchangeable stored format for a single CBOR data item.
This new sequence of tags is expected to be trivially ignored by many
existing programs when reading CBOR from files or similar units of storage, even if the program only
supports decoding a single data item (and not a CBOR sequence).
But, a naive program might also then transmit the additional tags across the network.
Removing the CBOR Tag Wrapped format requires knowledge of the two tags involved.
Other tags present might be needed.</t>
      <t>For a representation matching a specific media-type that is carried in
a CBOR byte string, the byte string head will already have to be
removed for use as such a representation, so it should be easy to
remove the enclosing tag heads as well.
This is of particular interest with the pre-defined predefined tags provided by in
<xref target="ct-tags"/> for media-types media types with CoAP Content-Format numbers.</t>
      <t>Here are some
      <t>Some considerations in the form of survey questions:</t> questions follow.</t>
      <section anchor="is-the-on-wire-format-new">
        <name>Is the on-wire format new?</name>
        <t>If the on-wire format is new, then it could be specified with the CBOR Tag Wrapped format if the extra eight 8 bytes are not a problem.
The stored format is then identical to the on-wire format.</t>
        <t>If the eight 8 bytes are a problem on the wire (and they often are if CBOR is being considered), then the Labeled CBOR Sequence format should be adopted for the stored format.</t>
      </section>
      <section anchor="can-many-items-be-trivially-concatenated">
        <name>Can many items be trivially concatenated?</name>
        <t>If the programs that read the contents of the file already expect to process all of the CBOR data items in the file (not just the first), then the Labeled CBOR Sequence format may be easily retrofitted.</t>
        <t>The program programs involved may throw errors or warnings on the Labeled CBOR
Sequence if they have not yet been updated, but this may not be a problem.</t>
        <t>There are situations where multiple objects may be concatenated into a single file.
If each object is preceded by a Labeled CBOR Sequence label label, then there may be
multiple such labels in the file.</t>
        <t>A protocol based on CBOR Sequences may specify that Labeled CBOR
Sequence labels can occur within a CBOR Sequence, possibly even to
switch to data items following in the sequence that are of a different type.</t>
        <t>If the CBOR Sequence based CBOR-Sequence-based protocol does not define the semantics for
or at least tolerate embedded labels, care must be taken when
concatenating Labeled CBOR Sequences to remove the label from all but
the first part.</t>
<aside>
          <t>As an example from legacy PEM encoded PEM-encoded PKIX certificates, many programs accept a series of PKIX certificates in a single file in order to set up a certificate chain.
The file would contain not just the End-Entity (EE) certificate, but also any subordinate certification authorities (CA) (CAs) needed to validate the EE.
This mechanism actually only works for PEM encoded PEM-encoded certificates, and not DER encoded DER-encoded certificates.
One of the reasons for this specification is to make sure that CBOR encoded CBOR-encoded certificates do not suffer from this problem.</t>
          <t>As an example of mixing of types, some TLS server programs also can accept both their PEM encoded PEM-encoded private key, key and their PEM encoded PEM-encoded certificate in the same file.</t>
</aside>
        <t>If only one item is ever expected in the file, the use of the Labeled CBOR Sequence may present an implementation hurdle to programs that previously just read a single data item and used it.</t>
      </section>
      <section anchor="are-there-tags-at-the-start">
        <name>Are there tags at the start?</name>
        <t>If the Protocol expects to use other tags at its top-level, top level, then the
use of the CBOR Tag Wrapped format may be easy to explain at the same
place in the protocol description.</t>
      </section>
    </section>
    <section anchor="ct-tags">
      <name>CBOR Tags for CoAP Content Formats</name>
      <t><xref section="5.10.3" sectionFormat="of" target="RFC7252"/> defines the concept of a Content-Format,
which is a short short, 16-bit unsigned integer that identifies a specific
content type (media type plus optionally (optionally) parameters), optionally
together with a content encoding.</t> coding (see <xref target="RFC9110" section="8.4.1" sectionFormat="of"/>).
</t>
      <t>Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the representation when it is stored in a file, in firmware, or when debugging.</t>
      <t>This specification allocates CBOR tag numbers 1668546817 (0x63740101) to
1668612095 (0x6374FFFF) for the tagging of representations of specific
content formats.</t>
      <t>Using tags from this range, a byte string that is to be interpreted as
a representation of Content-Format number <tt>ct</tt>, with ct &lt; 65025
(255*255), can be identified by enclosing it in a tag with tag number
<tt>TN(ct)</tt> where:</t>
      <ul empty="true">
        <li>
          <t>TN(ct) = 0x63470101 0x63740101 + (ct / 255) * 256 + ct % 255.</t>
        </li>
      </ul>
      <t>(where <tt>+</tt>, <tt>*</tt>, <tt>/</tt> and <tt>%</tt> stand for integer addition,
multiplication, division division, and remainder as in the programming language C <xref target="C"/>.)</t>
<aside>
        <t>This formula avoids the use of zero bytes in the representation of
the tag number.</t>
        <t>Note that no tag numbers are assigned for Content-Format numbers in
the range 65025 <contact fullname="≤"/> ct <contact fullname="≤"/> 65535.
(This range is in the range reserved for Experimental Use <xref target="RFC8126" format="default"/> by <xref section="12.3" sectionFormat="of" target="RFC7252"/> for
experimental use. target="RFC7252"/>.
The overlap of 25 code points between this experimental range with the
range this appendix defines tag numbers for can be used for
experiments that want to employ a tag number.)</t>
</aside>
      <t>Exceptionally, when used immediately as tag content of one of the tags
55799, 55800, or 55801, the tag content is as follows:</t>
      <dl>
        <dt>Tag 55799 (<xref target="wrapped"/>):</dt>
        <dd>
          <t>One of:
</t>
          <ol spacing="normal" type="1"><li>The CBOR data item within the representation (without byte string byte-string
wrapping).  This only works for Content Formats Content-Formats that are represented
by a single CBOR data item in identity content-coding.</li>
            <li>The data items in the CBOR sequence within the representation, without byte string
wrapping, but wrapped in a CBOR array.
This works for Content Formats Content-Formats that are represented
by a CBOR sequence in identity content-coding.</li>
          </ol>
        </dd>
        <dt>Tags 55800 (<xref target="sequences"/>) or 55801 (<xref target="headers"/>):</dt>
        <dd>
          <t>the byte string 'BOR', signifying that the representation of the
given content-format follows in the file, in the way defined for these tags.</t>
        </dd>
      </dl>
      <section anchor="ct-examples">
        <name>Content-Format Tag Examples</name>
        <t>Registry <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of
        <t>The "CoAP Content-Formats" registry <xref target="IANA.core-parameters"/> target="IANA.CORE-PARAMETERS"/> defines content formats that can be used as examples:</t>
        <ul spacing="normal">
          <li>
            <t>As discussed in <xref target="tag-wrap-example"/>, Content-Format ID 112 stands for represents the application/senml+cbor media type application/senml+cbor (no parameters).
The corresponding tag number is TN(112) = 1668546929.  </t>
            <t>
So the
The following CDDL snippet can be used to identify
application/senml+cbor representations:  </t>
            <sourcecode type="cddl"><![CDATA[
senml-cbor = #6.1668546929(bstr)
]]></sourcecode>
            <t>
Note that a byte string is used as the type of the tag content, content because a
media type representation in general can be any byte string.</t>
          </li>
          <li>
            <t>Content-Format ID 272 stands for represents the
application/missing-blocks+cbor-seq media type
application/missing-blocks+cbor-seq, type, which is a CBOR sequence
<xref target="RFC9177"/>.  </t>
            <t>
The corresponding tag number is TN(272) = 1668547090.  </t>
            <t>
So the
The following CDDL snippet can be used to identify
application/missing-blocks+cbor-seq representations as embedded in a
CBOR byte string:  </t>
            <sourcecode type="cddl"><![CDATA[
missing-blocks = #6.1668547090(bstr)
]]></sourcecode>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="openswan">
      <name>Example from Openswan</name>
      <t>The Openswan IPsec project has a daemon ("pluto"), ("pluto") and two control programs ("addconn", ("addconn" and "whack"). They communicate via a Unix-domain socket, over which a C-structure containing pointers to strings is serialized using a bespoke mechanism.
This is normally not a problem as the structure is compiled by the same compiler; but when there are upgrades upgrades, it is possible for the daemon and the control programs to get out of sync by the bespoke serialization.
As a result, there are extra compensations to deal with shutting the daemon down.
During testing, it is sometimes the case that upgrades are backed out.</t>
      <t>In addition, when doing unit testing, the easiest way to load policy is to use the
normal policy reading policy-reading process, but that is not normally loaded in the daemon.
Instead, the IPC that is normally sent across the wire is compiled/serialized compiled, serialized, and placed in a file.
The above magic number is included in the file, file and also on the IPC in order to distinguish the "shutdown" command CBOR operation.</t>
      <t>In order to reduce the problems due to serialization, the serialization is being changed to CBOR. Additionally, this change allows the IPC to be described by CDDL, CDDL and for any implementation language that encode to CBOR can be used.</t> used that can encode CBOR.
</t>
      <t>IANA has allocated the tag 1330664270, 1330664270 or 0x4f_50_53_4e for this purpose.
As a result, each file and each IPC is prefixed with a CBOR Tag Sequence.</t> Sequence tag.</t>
      <t>In diagnostic notation:</t>
      <sourcecode type="cbor-diag"><![CDATA[
55800(1330664270(h'424F52'))
]]></sourcecode>
      <t>Or in hex:</t>
      <sourcecode type="cbor-pretty"><![CDATA[
d9 d9f8         # tag(55800)
   da 4f50534e  # tag(1330664270)
      43        # bytes(3)
         424f52 # "BOR"
]]></sourcecode>
    </section>
    <section anchor="headers">
      <name>Using CBOR Labels for non-CBOR data</name> Non-CBOR Data</name>
      <t>The CBOR-Labeled non-CBOR Non-CBOR data method is appropriate for adding a magic number to a
non-CBOR
Non-CBOR data format, particularly one that can be described by a
Content-Format tag (<xref target="ct-tags"/>).</t>
      <t>This method prepends a CBOR data item to the non-CBOR Non-CBOR data; this data
item is called the "header" and, similarly similar to the Labeled
CBOR-Sequence label, consists of two nested tags around a constant
byte string for a total of 12 bytes.</t>
      <ol spacing="normal" type="1"><li>The outer tag is the CBOR-Labeled Non-CBOR Data tag, 55801.</li>
        <li>The inner tag is a CBOR tag, tag from the First Come First Served space, space that uniquely identifies the CBOR Protocol.
As with CBOR Tag Wrapped, the use of a four-byte 4-byte tag is encouraged that encodes without zero bytes.</li>
        <li>The tag content is a three byte 3-byte CBOR byte string containing
0x42_4F_52 ('BOR' in diagnostic notation).</li>
      </ol>
      <t>The outer tag in the label identifies the file as being file as being prefixed by a non-CBOR Non-CBOR
data label, label and does so with all
the desirable properties explained in <xref target="RFC8949" section="3.4.6" sectionFormat="of" target="STD94"/>. sectionFormat="of"/>.
Specifically, it does not appear to conflict with any known file types, and it is not valid Unicode in any Unicode encoding.</t>
      <t>The inner tag in the label identifies which non-CBOR Non-CBOR Protocol is used.</t>
      <t>The inner tag content is a constant byte string which that is represented as
0x43_42_4f_52, the ASCII characters "CBOR",
which is the CBOR encoded CBOR-encoded data item for the three-byte 3-byte string
0x42_4f_52 ('BOR' in diagnostic notation).</t>
      <t>The actual non-CBOR Non-CBOR Protocol data then follow directly appended to the
CBOR representation of the header.
This allows the application to trivially remove the header item with
the two nested tags and the byte string.</t>
      <t>As with the Labeled CBOR Sequence {#sequences}, this choice of the tag
content places the ASCII characters "CBOR" prominently into the
header.</t>
      <section anchor="header-ct-examples">
        <name>Content-Format Tag Examples</name>
        <t>Registry <xref section="Content-Formats" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/> of
        <t>The "CoAP Content-Formats" registry <xref target="IANA.core-parameters"/> target="IANA.CORE-PARAMETERS"/> defines content formats that can be used as examples:</t>
        <ul spacing="normal">
          <li>
            <t>Content-Format ID 432 stands for represents the application/td+json media type application/td+json (no
parameters).
The
parameters).</t>
<t>The corresponding tag number is TN(432) = 1668547250.  </t>
            <t>
So the
The following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR Non-CBOR data for application/td+json representations:  </t>
            <sourcecode type="cddl"><![CDATA[
td-json-header = #6.55801(#6.1668547250('BOR'))
]]></sourcecode>
          </li>
          <li>
            <t>Content-Format 11050 stands for represents the application/json media type application/json in
deflate content-coding.  </t>
            <t>
The corresponding tag number is TN(11050) = 1668557910.  </t>
            <t>
So the
The following CDDL snippet can be used to identify a CBOR-Labeled non-CBOR Non-CBOR data for application/json representations compressed in deflate content-coding:  </t>
            <sourcecode type="cddl"><![CDATA[
json-deflate-header = #6.55801(#6.1668557910('BOR'))
]]></sourcecode>
          </li>
        </ul>
      </section>
    </section>
       <section anchor="changelog">
      <name>Changelog</name>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The CBOR WG brainstormed this protocol on January 20, 2021 via a number of productive email exchanges on the mailing list.</t>
      <!--  LocalWords:  prepending COVID exfiltrate
 -->

</section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="J. 'Jeff'" surname="Sipek" fullname="Josef 'Jeff' Sipek">
        <organization/>
        <address>
          <email>jeffpc@josefsipek.net</email>
        </address>
      </contact>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1925LjRnbgO74ilx0TTUokm2TdqZE8peqSXLPd6nZXjzVh
y6tOAiAJFQjQSKBYVEVN7Kvf/Qn+k/0Tf8meWyYSINnqudiOXU9HzKhIJPJy
zslzP4eDwSC4n6qjICiTMo2n6k2mTJkXSbZQV1+/eafiLMyjOFJJGa+MyvGp
nqUxDdKLONCzWRHDDOEsLwbzJI0HK71IwiDKw0yvYMKo0PNykMTlfNAaMxhP
gkAXsZ6qm6yMiywug81iyut+nxd3uIlvi7xaB3ebeszgJc4YhLqcwi6iIMwz
E2emMlNVFlUcmGq2SoxJ8qzcrmEDN9fvv4F1qnKZF9NgoHhbr5NwqeNUvcP/
FpHJs0CpvIDlb3UWxelKZ+o2n5cb2CBtxsDzeKWTdKpWYfE5Hug3xg4dhtrN
fKULU8aZ+jov4Imb9ndZch8XJin/z7+V6usiXsGQ9/9wA49NWcQxHOZtbsq5
Dpfq6Gh0fDyCJ2FSbqfq5WByfnRyIS/h13mVlQU8+TbGJbbw1XqZZ7B25/Pj
i8HxZDyYjM8Hp0cXk3Gn3naoZ/lvyp+TIewnQLCVRTKrSoSKUnb3v81NPFfP
fxvP58/VbbKO7+Chm+In+Hod/uYnHGTw4RCRFmR41BLOhzPdvn95cTylt76c
qnffXJ1fHF/Qxygx61TDvmkIfIUPz44ngMf4n+HjFb8llHiTzXlaILoyDpdZ
nuaLrfr3//2v6m2RLwq9WiGBpDpbVECJhp5c0QwW2Yr+EfiZemg2nao3xUJn
yc88OSyjbktAJdCBfMfb1SVsYzICUI5OeWe6WCCmlmW5NtMXLzabzTAxOQL0
hZEZXpwdn0zOh8tyldI7Ji6S2CRwGLufm9s3L26ur6bq4vziYorz99U3eVWU
S3UdJbR8kNjDM0zx0jSA08FvVDfMV0AAUa/T2F7H7i/OhpvkDvAUJZo2iZ9e
fAOv/virybm8/KvJRecQ1L63bzcAAvQ1AhIbCQZPx6Mp/3k2OQFkhrle8+fJ
aKq0CZMEPt5cfnc5DPMiHqw14C4GdJip+x45Q6kXRiY6H43Ppmp9F5qxfHE8
OUcyyQiq8MXF+AxGZPFmMEvz8I6/PD0/glEr3HARL+C73w9PL0YNwD0/QFYD
dXn73XDM/A7pqqjSGFjK7ToOk3kS8gv5XH2tDbA3htG1HfwOB6vu19fven1g
AFmewRvpzvMreK4A5OplYkr4vkrMEnirHSazyuCXMPj5DmIGQs7vfzd4v4OU
ySGKw9HqXYwYj4FK8SxTBk6bJs/PJycDBPrry29vmheyo4twCQSpumkyK3Sx
7RFdKoZn5+ANmcVpOkj1zAD6Vy8qU7yIVgU+eQHkdzIerqP5szXc4C+PvQON
L87GgzGc6WgPCJhVvYyzLDHAwUvYVkyPinCqvpIjJcCCYWX1ClbuI/t9cHwj
Lp4b9VpnlU7h6iXAr+3Nmyq8HXAd8UgmCO7jrKKbJywU6PQ3yPqJhyq1SMpl
NRPpt1m8oP+ycMuq1SwugmAwGCjYQVnoEDjl+yXsGGRjBXgoVRTPkwxwrUmc
AiV06V53egJTYk0kDgEoWmRwudRlALPMActZlG5VmStELHIy3DtKPVUArhcZ
HUmZraEXTQWyReMEMYMDh3fHPSWMYMibXSVRlMZB8Ax5ZpFHVcgs6TbJwliB
DNuqWBewLgAY3lxXSMl9la/jQuOfbr2lBloxebVYlmqjtwY3utLFndosQejS
6gZlWRqpWazWRR7GxgAQZlsZsWZ0mWFwk9GO+yrG9cslLpMw3EB/WOG9nG3L
2HyhkggAm8y3OAIPimIOvjE4ZGc4rBsCKcGDZVwVeCdDBWhK7kHuAjSACuCQ
yNjDuH8QbH3Z7RJAGz/AJHAEQ7ACGj5Sj484/umpTwMQoREsGtHioAKQMgWA
sftWKND9ewXjNEKlWiPDap0IP+NY2OxrfM+CvvsqySoA10qHb277wMazKN+Y
ntokcCFMnMZhKXMVBf6t1+vU8rjWcrQVu2ZfJbwoLwQqRaayHAkZ2DmI4xho
FPGXw5gCGLHOAHlNMCLVpBr0M2SQr3l/GugVCKUI6dBAIAApuHBZCf+Lo8DE
KDLKGGhuXuSrelt0K/A+wKxhWqGeWl+BpGb0XwQl3jsgQkbjm1uEt05hwgwp
Cv4/xpcBD3dZvgEWLTQGGlNVuvUCWs/BH0bX58YxJHhocYsPhoPFSpQr2sdM
EBw/wESoqAKQaLhc4008QyaO6iKsUCDLddMP2mdjkOzMF/ytvqcTeLuCy2/y
MNFIoRvgXLv4JYTq+zwBEs5XcSAkNiuSEkQAsCqhOrx7a7ieoK0Og++XcSa3
eYYiJkZFD2bMgLIQI4KypNjBS9/xpA3OoUsA05p4CMI2R2LAA4VkeGhAN7BW
vF0ET0IlkGvMiGpdI9w2LQf79aHF1GIsw02EaeK5ZfPE4ZLVOi+AYkuA5KXD
i94eXEPLncXDJghIC9EECSUAvTdEPtMh4aBYOHTgxHybQGyW/n2uX398JEH8
9ARMkDYO1w0plYm+RXZwjRYJihrRblawbBnDHAOrEyEfApLwNkF81NwhovKC
7re+B1mHAO0jZojNNsmLYbKE+xNnC7qybuMeX8Q3wYCKLcxLATKebV4Jo8f3
nMp1b4Y+h2tzDnj7MosKJM6OXt91VBe2RxMBUuDQmZnDcXBlQi6O9/haD069
xeUFfQm8p/Fs/3DzVnjoZcRKADKGvprB5VVv1nH2Zg76X0wTv76VD0zuaBva
1+lm/P71K/7Qp+G4ok5N/vFlg0vDQp4JEB+ueP8R/yHk5+CEANdwgyMgVg1a
QLklCixgepBeyKSbQnCFK/5UgZbTwXU6iBm4vDPA8ZbYt6nwVAnBvKmhwLD7
JKI9CfWzQ2CHiDLEAbIKoEBQy2BhuhR0LqvMMJBN62sEEmARpTO8BnTWVHgU
HZa+AyuxilGw5vPAU4iAvOEJUHZQbnK1zkG2IDcAE2OZR4SWOLuP03yNu6L3
EG9rEDlwwjj6wk4P2mGZh3kKPNckiwxOxeKSLAAAcQa77162xrIW0jASWB2A
Iwla8RLBTbboG/baaiCRyALYPMwV3SN5kWjhTdABGmsiNwzCZZ4bAnMWC+cw
eGa4lqAUr1jTaNEBcGDLVwTPshz85RmcdL2BxxeRwJAOiXsEagDw+ioaiQIf
mwBWuDIkTDXpaPaCOq4JxtGA38CLIhtpLIeKEilHxDWJST8+LmNQmgrz9ERK
GxJMYvlhwGLaP23NE5kVgyJhXVoD69KqSUg2IUoEYRQEANCQ0LwI4RbNk95N
4ByIqhZoIzo9gQgIE21h5LmgZWTIW/G2wXEcxADW1w8a19qH57AC9Swr4ZZW
AFLUHImOiWhks+oqz8LExIFzVt0IoxFqfA9WNVie+e33Ny/7sKW/uRm8HJI7
zuhwBRs0wEiensguDa7hTeAmlyCIgevy+/kdcH3Vvb5833wdpIwZxLqEd4fB
1Zvba6TyOJ3jILTYxycTQFZC8DeAGxa380KDgAKboipiBLvH/uH862oG/Frd
xVvjwEQwNWGRzCwp1HuA3cfsVhSkDsK4gB3hSz9enYwuflQbMTAywEvJ8llU
hsznyQ3I0w1Y6Z9Y/KyTonYUlY2biyJuhqqaNTdA89FFodk4gq0A3QXsWGC1
2qqCoO8Aqla5KT1R8vb6tfW3fiEXGr8mNQdkkr9dKzqtSFaddbzq9EW24m48
UPbhVib3qAnwJ9wYEwhqDMBTTSkC6/bF65vX17UABt2O9GlCE9FeXFM4qR+o
SjW4n46ipsKVqyWo1FZ1xgei4LWIHY/a1MoMqXhFzNectpqQD7RklSJOSL22
KpjdIUpbqw7gbGLIbBKkuL/NN6jx25lpUdT61m4fzNhYWfCIZsn6NCusTUbg
LSD20dYXMXh9DeviUTKHTeEBumm80OG2V5O/CUFSy53gN0PL2R3mSc3ltZ0w
FK3K8lmUGjoNCEBtwYa2B9E+DYY7kq+Zn8N7WvGO3D6CZ8/Ue7JuyEMWBF+D
ySzybgtMfLuiC5GDkl/yrtEWUh20rNHQhnU6gLM5ijBRDmqh7tHQ4yO5g1HD
9WYhPwjJD+R8QBc5n64kzRKtgQVgpwAbEnk0a0RMPQFIIAZ8S+MHNG/wbzDa
wG7xLBNQMRLQWmAuIvwHVMWDyoCtwfCHd5pzfkECnUfYW+B4AiJ0tQZTKzYB
iBFQpQs4RMIGu4RNeFKkMXKS1GSRNJh3wLioXTdrVPLwiUG1iIUc+T9NA3jw
9SLLyZ0BAoemaqNiWYGOPihAqBJN2WHBPo9TE1kx+YPUOR5HMEe8o370LT4S
z3ATrVcvX75CYUQiS73EJV7i5OyoeiWu/F5zr4F18Tc30l5gXmW8/PvvumHZ
Q5Q3xocleZhpPJD2u5qbGKGf13SxvhPH3eWOmWR9BmgPgeFTAFe1rIgINYEb
yVfJskQGpeUtfcsRrOU2J9fjPN6orlkhh19VaZmg4gEAPO6Jk8qzC/sBc6co
j0nzQSsMTTAynxvOIX7AXN2Njkg3q307aL+BkdN0JL1CK5+OClcmrZjaiEw1
0F+JYRQ+MzpNCEcz5EklXimwmio6HW+TOCsfAgfLWGBQeE+HnnDZ51ezjK3M
U1Yg6TUrVXnaPt89HJkCKRPwV7NkUQFBoW4ZPHPMT5RuS6OCCdj/JvftA7Ea
hsHXaP6hmkkoJC2K2A6phMwSDGBLvrWOIPYhMl7PcTvjCe+UTgsgQXU9sVBD
Noyu3Gptr+UBQ8R3NX0BrB9tetbd4fIB8QYEaTh2hKay8O6d6WwsA0+jHp8h
kcKNeArQvUrW7i4c+sH+HdUIzWeEDhE1qPTjZYoxjnmXABaBuPLZT+xwZHfH
Vq0S9AmzlW5lPVmGtVAmwxfeyNSxmoEZRqqFdUyo4wFJGbzPVpKbpfUkp+Ss
AiibiqaHi5WH7JrWdNnQisX91fO1tT+EHQamwJoEJYrli6zpkYOR2MEVAp//
vEW3HVwDMJbwPlveIKpLJOKTjYsEQ5KaybEbDxfDvroHfo7eP4QgRhx67KfD
rfStBgLQSq32BccmvuFcPWKvt3j1xXDicWtyp5PvSt7qiyllqsUiJv81Xjex
LzQzY1I1SnZgBk2NrwucWP0e/oENkebZApV9mv8lqe1riZwFBo4Ewi00Q/WP
/wvH/1MQyB9T1f0uL2kBnAyDMXkxVW/hUhvUUcV9BifNQzaKQmaMHRhO8R6c
plN7NXEWq50xd7Ost6WtAoWCEMjvOX5E3AQ9bGikXwrdcNzP3U4kcZ/1kfQi
n6oo5e7Wem8Fb50M2CxzYliCKuSq1qymqWnXhKO8iPjuz2InMfKqYDosav5u
cne35PZkeYD8EMnl57jIhQfvzOGbXkQQbn26VcG9TuEKNQ9LA2lxNXoYjUf0
T3UjgCqQYjA+PTs7m4xPe/jC6OEb+ecGqOPJxfHF6dnk4qTHNGbI5cDOzTlG
wdFj7lMi+6NpLxz9EmmUwR0BmxCp3R0SpgzsGRviM4GPoOIV25YqB5JXdKvR
w3gyGh0dn5z20PEZiEdFb63DUtG1Xdk3ZS8YUWIvbkNdIB/flejBwlFwDg5D
1Y4s3unvbgeXt1c3N+gyoIA5sHW0A601QhwxAzrNYAXRitaeVo+IrFCxFAmM
wt7xnC7Thbg/YbuGNp8H4srjIIVvszlvHhCEFTdOfWJlCYDPfote2037+Ag2
WGY2OoOx5AXrvHl7+13HeozQMkOu41RRmDYQqI2Pjkanp8eTs5G4sslrQK6s
UgJy+8Kh5EohTrVP8w9q98EMlber/PItuk3Ic8ORXlH6VLfmmePJ8AjxY104
wTv2rW8DgEXT7YMa7c6UpvfrfSkPT08YVHl83P+s1w+0dwvJEwZ4HlBQEuNf
HDNkxmS5fKIzPajR023hK+CYI0hpNLKBXQjiTI/1hOta6L8moT91Mk59X+j1
GtZ5fLbhv56YkncGeI5CjAuBZozSCFdGoie23FCFBW/OmbzX9Wud0c5qJEpn
Iz8SIgXtLRNOQekjtL28KpFxagkS38bpfFATgeXifXVycnZxQZe95WGyRHA0
PB6eNkQn2zIws9CAZZ2tJU0Mz+ulkOmbuIXZoIVMdvrSNli0W3Wttt+z+zwl
/QK3nJiwooA5bdlqc0/D/Vsk/2ZW75FW2A91BrugFBFvaulXI0Mbdzy0hSsy
jaIc9Lg66GJqS4Gsd7Q+OOBFfp72jGGRg+2hKaUP+ATZblkMOC7uiH1tErPE
eVhiM/MAAqAdSGCaQ4wm8NwGzsx3HFPM/L5irYsG7OULwRvWXjy+cDIcj5gz
SMIT+T/bYYGmlrEimwF4GQY01ToJ75oIDjU6C9gnWO67XjuKedOG2Imxl1bF
ltgFuyv4Qtr0TpLjDYYZkB6P5JhyxA9G4xvfg0aqQ8zOqKULXukkq0G6gqeU
hUfpKTpFz8LW6Ti4VhbjDCiBBfzEfoD/MDsCHgN4HCC5DYRDIbMhHzt7jD2h
Q8ujz99KCVbuM1Tu8WJvWNiimGwxerl+nnSh2zOg1DIxpj54YcMX9OBz9DF/
oIDjGt62okDtiIKg+4lSQH1cChDARCaCJAqC3xmLM0paI1dDi2k5ji9WsSdp
rUAP8PK//64Lc/bUl2p8enp+cnx6MblAVy/rzvgighCXuo2z1684WLPWQLQf
/vFxNFUdCUt0+up0qo76ajJV4+HJ0z99cM52j00DyLqwvT0uqR5w6z/84Q+c
PIXPA+LH3XpX3Y+v1+vh+0HwBmlfLeMHnlBmBMouy20QXajoYn6m9v97hoft
0rq9gJLP1OnR2fFofDbeP7TeXE/yzM53RtrxFAnoju1ATGM72jtwpdfdI28Y
/AOdemdYlZFhEXVHzbGnO6eDvcIF6541x+HQo7OTs8nZ5PTkND47hnEOuM3V
Tz+y+mlrpztn8sa2TzX5yNhJc+z8Qh3FDTA8wzjGKkFVqDs+OT+bEP6BAC7L
PdxMpRgtY0IW35zvtkPGdvCiU9RqxUaZCPhzMSeiCySnSDsyAboDeTxH8W9j
origjvIia8i47vl4OBy6dAm6XPSkJ3oTxU0PKmWv9CxO7YS31oJ4fGaNCSO6
2f5xn6qg2RfMnribpGuLGlSrCBLzNcyB023NsskVItlbnqAXZtRYkBH1WYq7
/0z0LPrAChUqedZSFZHfV9a9jpIQhEFEWbVh6SR+cEBPhVfpxBgCdDqRpy1p
PoHOSkJ6YK04UqyAe6Utz6nbZ+3tC8ZDtaOKktDfo4w6LIlWej4aDYMJT9BQ
2rSnvDq15oATCoS/ZrCC2OMLgEmbNobo6XS14+vSeKTgwU1ukbVfaw+C7Ku2
P3293jgxXTshhsERn8sHOZ2sXBYxe4slG6aOI3khfGQRo4fjyQ8/Hs9/+PFk
orrPYfBzdUDEDHcMgszHWBMYpPNoGyPTqkWfzpVuciGfNA2sw6cgPyLeLAyu
xpgKuk71bthk16JwGeaUdQSqm3PXI+i1zTOYA6MqLdluKU/RS/iV+K1LiUB3
SRKhX50MLFTs4CX70aWiMHQ8EjsAHWZsO8FE1D37TUahZzllkDTnbSC6cbcs
hnkFcpW6zBy0cgDXR4Brh2+mRHaWYOUOWMbojebEJhseSTzi3sn2cAyYCG7g
bSL44wkLlgfDp+2257RUzIrMwbrb2KTrDEOLbh9d07PwbhGavTWaDSf2t2xr
55g1GwCyw6ZjqclN0LTc8NJ+gi9lyyX3CRlsninFUQsCkfOjWl4Lx71lBztp
iER35Ey6T+KNdaxQTFF1owRzijlBXGdBTM7cviILhVKtH6JqtbbVQD2iecq0
si7nj2AYbxgGQTCqLu4BdlLaFCWXCExO9q1LFiodPdbugtqziR8whEJZv3DW
PYYJiNn/CrvEVbjss02ozi1b8ABDugvuc9dQ2e+z+lRDJThsqCjPUAG18i9u
qMCctaFyNroYWdWDvSw2pM/FbCj0BBF9vnM8kHipnyZrSyjS5C7mAooZZ1km
pThiJE4/DL7LM6AKUKiMVRpqE0nALxF4mA2uz4dRX5331fikNoaCP9UYAjWg
W5+c+VEPjMNRPzjvB+OTT7B+nrUyJ+kExypmP7YR6+jcNxzIHoKlG/bQBDSb
hgWEO7L6+vFR/ToJ+Ybafzw5ngM7BVMDL3AAGn3Tkhmd+1+cwxdz/4vxyZ+p
5X/ilTms8gek8p+Lyo+Q+BSV34I86IIy56n9DaJhmsHUz6xtBGApzgyMboxh
X7qsUCdjXtog0+MzCQS3s0oTqd6hfMZwmeMMs7jcoNORvLnMm/Yn3dI9BJNl
rROMY/UayZXO7UdMXbT/ZkodjbOitzV3V4Q0SKKqyKxuZyi9gFbbv1iPUyua
Ik7mYm/XzHk03WI9zmHDXAQWX7p2Wbk4HbDkvwk4KIoAZL8qlSdgtF4bU61s
5Mnlo8FRJaxd56xxnnwfOe8SnaYiqK14lJoZLpSy0hA1u2RR2QxDTsFAb54w
sint2GXvceYWpkZiwqXUXIEgwqz+OuPvhZ/hh4NPRhfow/zlxMmesiEWlhNc
mxNiJDJC963JUUZxZFEOjoSNzLtgPi61133J237z9zcvB+MLkNJhmHD9bSP/
cCeTRNQCPuXfvaMwmE2VpZyM8qCNq8W7LLEK1jwliaSl8DBKsmbhE7tnjRCz
U8ycYQhyvZFL+BFzW5Y1KRJmihVzJuFYrihcmsKxlABK3t++xEd0YVDbIX0I
WDheEFCPKJqISWR9e8jMPi1bWmhCpTF8LVxxXV3QhNnmKc/CT10esfPlE0o+
i/LP/KQdip1jcjuf/A0vzKHDJVXBSXrCYfQkXkGZBCdlMQzs22I/MSAf1pQy
ktM94AIrKSGgYKit9zF3yVqRCsDGkqUiXQNDpLaNE4j6p4u8yiJrdrIV4JkC
YuvXJmmMFfdWmbAJU6y6SWgBdy8yn+rhkdgoUO0qGyktJCltJBY4QoViygBA
98CzQQ94Zkl4JIUlhb8ksuNQxhCYcgUhb3HFhCQ7wHThQgvnXmnqr1BlbEnS
NHVCjCbnjvajwhjksMe0eS0IDEYVo16CXIaOSBUnkrXFj+r1uerFU5xhvy7+
UcRUAUisGjYjGFyjsZFXBmNrVYFp6pJM3Vedt9evOxYdPnfh3OpFwUk/s5pu
ROjUCXfeW1SgJzk6MA6/ygQCv/4fIJU5UwUh8PZ/Xt2OnYaJxZzYDCOxqSVb
zmJKMmWbA3DO6FANBl8RgfEEsnHQ9qninWL/JKvQoLE7bYoBkT1sX1oBQ6Ug
hdQMeVDgwWZKTrI8S7ecLwiTYsY5rw7YzbIcJS56IexzSZl4ee3qO0CKUN04
Ku/MZFCJlttmrHcrJTdttuj1mxBENDcgjXimPEZMmS2pboeQTYzRsQS2n7cg
GyKP5Jib6sjLFaPsOtZfHK9pJl/seATlXOjE8ng0qE6Y+Y0aR8ZVvVJ4hWNp
h+5LZKVVxvmWrjVKPbGkJn8kvo3WoZ8RUkpyGZ/SceBahEkCJSKd2n+4rTiA
bVhAsJxmcW6rRClz+FBecl2o4jM1JJnAVGssiURfjyQN6R1tC+zOLBJzq6EE
gxr2dUXKRKaT+3pm1tuIzkmmiQbBPFW7cjzhThweZk8KBYWHwTuUpg1pvQe3
TtggqwO5tHB59XX0WCLrwImJBdOXNmXMaZdcJiwK2k66CeXACmCsi8ar2bU8
M9RFkZB6E+gdTycbMr5jDOuemIvboCoJFaKJwCoz1o+vbap4a29W8tRJkkDs
KEcCz/8DiEq5pgwVJ1yXbt4mTtOhM7qxSAeT0MMK6YdSGEGg1g4jWHVg064F
iJKROCMvRCOLqIaO9TvvSc1h7wKVNDcqNmxZkSQauOS2gur7QbTeA8eg4hZ8
PqWwyg2TT54NqFhD6AMuIOr/833P+H5KrTHWsFoA1sq9O/tB3sIzs/SLmZgo
lsSpemUt6VjtaDIQdmZaywpj85I31dzp0J2gvUItR/1Cla4oklsp0tVcvGIZ
OfvA69KtnoDgsHon261JDMzhdSnEWbaPxWGuK52xusK5XA0uVwuOOKrR01QT
if2Xy/1NEdyFqcWFVYQok9TL6fTyyXwttYvIITXG+Uc/GQ6i5KFQIauDJUpJ
7OO9x1wt55EkkSLfqLgo8oL49EYXGPQwFnMHFGupOSLGgFvexiVnilVr7KYi
SYFk3eIqOGQW+1SHO7J3KwFbgq+UFKm5mgRWI+zJfPxYf4EIBBa7gDFKsxZd
hYqO4zCOrLqy/zAce7AwdnmLgdsGMTgaZVpi/rK27bnaLs/aQU2czCbFEAX5
mwiam+C6Ako4tukuOzEhqTbestwEfmo22I6GcrlqmmI1jZqWSNa2C/iR4l6I
+76uA5ImEjcejbrN8dlqN0Zd3TG3nShcqjU5wFBYlVgggYRMpgMaNDZ3ls/a
R7mEyDZEG6W+QzcRYCHwFDg4wF6kmVZSFuOQ06rgpgHxBXWAAcUHHO1xqpG1
PAVfqaYlQK9JLZpXEQm68s3vG8pjn1lHrSWGYbwuKfkOGyAhSHfeYaeLR6b4
hcuzNnBvqjV6ZTztGTS7BFT/ryhqSa+wkWcV8waPuM6igRTRdq+ve/5EfAlJ
16FWLdUM1kWXiK+sk+FAvY6ogkV1ry57XncSiuqx2wTWuuZdUSBe6r7FFZBu
Rc/HxnXEgH1INoFoVTZU8veNQOPUKUw2e9iVwjYT3RJp8nOH17QQ8m6E4RrI
iHLXfgAQIAFtaU5AfOmrHeqAfaySB5sJwJFPUgfev7qVpikeRZABhYYZk8ZM
/EdJEx6eYeX8K8lBkLk7jJ2DhPPAPSV41/aHoVZFtQ7vcapGMP1AtobeOu0T
naqNxHO1rIqIzdimNLQWciq2N0nHPVo6WSzkRxQxfOnsbla0va4kteR1rmc+
E2GaDlErzNTmAx+sB7Vbng4eyHE/pibVEpMbTXAA3e0GwC1tVASWviPX1pns
9LC6tc6Cq4a62HaW7/a5cP0KmrFdEYLD4CqVLlhtX3Xd+cV2xXF1ntrv1wFI
1TQTqQNk8OYz9nAkglDxFVEcF/5Kqb7f35vVvzF4LeqVbNBzFMYPsI2SmH5e
UMunak0wRcGPB4spu9z3hRosGkBfyjIO7yRHCe4RlxUQnRNSdTPTF1QQdJIx
XeKsMouNv/I8wiDAatUUJXZ3CStEjNXlpYHZz1Lx5LphDYOui/9lLuVVknZo
t9hFhqo1sP5r2POd6WDeAn9e5xgZogJdw8Xktg0gclzRX4kvgawk3Q3M39zL
jCAbT9ofxa0sqWYtMKV0h4AuTO7le5JTSwFqusWBH+Eht2ySo/clcgEV9Jjs
9FVrhAyMlDChBz4KvPyT3BodcAGIa8TZfVLkmZTPe0dh8zbJ5ikHrDilZa5B
4Wr4x22FuVOinQD1qiJFvwyooxuYd2Fp1b31XkqjGk0qtdu9oFh/Q49aph7e
ArwARIrc+8NV5fWFOwSFl6Nru0uCOLXjbLjbPmpm5NbfoqbyaKOEBJ8BZdk7
HEt+RV0rRmBAv1aE0oDcP4GrA6hztlWtTtbaYKu5lHvQxTwKqx+Rrc8+D45E
U+UUubMpvF6X3/SGwU55iK038JPJ6pJNiSSA0rjOkYslGFY4aJSrrq0lYfOx
EdyX8pL9Ao4rUHfhCtIGEY51L15hBAymkLRNpLFbPmgSBTv5k3W6XF3AabMj
hryoa4SFgm0tapZAuNlYC7sMJXy9G/fdJidYnOxm6L1oZOhh82Ph/5zFUne+
SULZiQ0h2Hvt5Tzi1JS6TAt2DyeZ2WylJaDL1uG1nFeWXYi+Yz1AcIypGj1E
Fz/8iP+bn3v5F16a2ftvBufT2kimN5oBaD/ZygsI0ZvWPI35PW0TJamExqX3
sKOEF5RnNB0SAk1zcGvj06nnVrOr41qwGuZjSCMRZLpazIGeWlelpJDIFmxR
HE+plsA2B0udztXPcNGtN5xtA27CoSRkTLkqR5PBDOS5TcGjOYdK+f1IPDtx
fEqjZ8liILviTYweAAXDA+BwRwN1l2wL4jfcjmdydj5GbvaGSjyoQtrObNvp
YRqW9d3UxRqNEBwXVoISzcmffgPEZC7Zh7QlONl7juw+SJ4ftWOQwa5UFowg
3nTpchL7rWYSbVoW3sCeHW9GDiSLieTZHOQ+4Vp9JDifKsgKpZRlmOHLDnYP
7zwF1JXiBiAyDaZ4DxZx5DtkOQbEhcJe2Fo8La5A1kofjPQEt9YcxykTgDoz
YJtRULf8ozyIpmkdsKMMG1dZVved7aBFWwVWFjgGJu18pHBWOKhjoON9DPTw
1Hu4aNdrxNX7K0/9i/DUi7/y1P9qnnrxV576/yVPJReGxJb0x5goGUNDx2qZ
l1EvpIPF4gYU2IZu/YtcWNJaJaBlq+/Ox2eqO3rgeqLRGA3kAB+djiejixP7
aA7/ekpbXzLGs34Jzn4UUVLI25l47dJ+rmrlZh4tEJe7qZcYzG9kFSuwan+t
Tk9GkxPuKclYodif8quff/gBPkufpi8VnvD4DA+vPlfwnXqhJicnPfUZ/OcU
voJvfoXfBME724oEd2R3ynzY1WQi1v6sdOeDdZm1KNnbEct2DHB1wa0szsOE
ZfvNo0nkiGlfybE0I3CN4yX0Rc5NLgBonNKrh9Do2ChKywRtei15kBbolyB/
U13xUcewA5v/RlHsrpdGvU4rbCFnW+aqGla9vvd9UOYLdn7IPbQTemUob0Aw
YKEwHcL18nUePml3XF/yuH0n53si8n0v2arBfBtGdmsi5+hukPpGwr+J2ZPv
SY6+YoXeOUp7pMFRPKsWC1tks9sm0ZnhdVOZP4UvYHOVXl3SomlJPETzAJzk
0cao86nZrH0iTueGty1mGpzEpjHYfjAlplrHUq2zkxOBGTd7PQcfwvKDJNTX
TCPowi3/DO9+32ZQNnte1ikKSckYoOYKFIB3EAw+MGf5wAFM4JRf/fG8BmDS
5fjnh89hox8+w/978YEE6YdffZBGhNSZRG6QTVfp21CloLqvouSeHJu22xBo
+RG3iKk92Tu/ZxNcAWvBvt+9RqyMSAnxVqWaO+MYP5yw2+1nByGBNQBspyEM
stQ5bVneIEZKIDDCLJhv7cvOsH13uDEQS4DHx8d//5d/e8J0ttL7cHpycnRi
3bg8Pql3S59xw4Uk6R7syEKhTYxFFAmFRlKEASdQ5KD9pXqNg2EfpBuScWFc
AjzRd+NlXtnmcgT80Xa6R63uoea6HnwQJH4HzuamjPUGsmGD/bbyrfJbvCB6
rx+QgbvG48Q+2EW4Im5Lv3ygTbtKte78TBc3kG4m5CkjPkQmX98ZfH4Rnq9H
vCfrEE0eMHdsn5enHopYjvzBGKWknrWlQUhcfA+hdW0plK/nUUGILT7okUKL
OUXNUGVbKLoYuVcayDNxWv2BAgZhHeXWKSlW2igltbW7aR+71TJ7T1fX6B08
HRtgNhW9dvZSU4Ahj6XT/8kHb+71YwcOSOtgFyrguK4Y53x/dg00THur8fmc
n+qP+mSHuZ7iem9NDlMl/T4OBjhaSqJQXjMkKh8wjmCVKxFqklIsynmT+yDp
uv7ZpDxZh/RTEBzu0vGX0QYtO2hJU4aKzxPoh2F4W3CVPsOIdqt5z07nk6d+
+6jj8YSFDud0qMbveuxtY4DpS75OhkT3fik/+mLWuZQ51Fo5EOOB3iBK3eYt
a5pauZosAfIu2z2IrX4F7x3YWks7IQ7DxWtRhL/wRUOpQAW28ux06PUEwd9S
6slwfK0WXU1FReqTnctLukS3uGHfVYjqJkxbJA1osg2H5bBoTzUqBgCzLZxN
znycebO3AHOgKK3fvuTwWrMklFDzCTjdV0b5l8Hpga3vqJ94B2zGETJD/Lm/
Vu7rDhE05/YJgeohm4RQ1+uSAvtGgmDAFVw8jA1F9+TmrYlD1L0oPY1cICAR
sMme6nbAtinzTk/C6BvOwy9yr06l2wGND3/mpsODOpslGHqdHqkg/Fs+VcYZ
I9jWU1OT20GUo/qnDJwoBuJDTcX2+FNXA9ca3//RAlJdpB0yQ8pwqn2R6DT5
OY5ce/EZksCd9zMQQ897JyUpjXxT5xd060oZZJJ6DiVN2bb0ZfEFi7U6PQ/l
U7UGkGD2BFtI7ic4rFkiULX1WTughIOBhcgFVnPsLh7ate2J7GFtJYohYw8d
UH4nd86wxa0Cim1aAjrUsE04anZmWZWl69XPu4ryDcz4smLrhpMpXEdUrAlP
VtbS1kY4jTswror2PSZeVJSDm9WGgBiCOdfZYFa7nZ3cwlhuYEqbb5LmOrLt
ZhOXXINilFFnn9msfonCWz9vXY/jMI0z1t4zPi32FTUlTMF7uHl75b0r73HW
UZ1sz33ta7p44VEeorT+lQ4tuQx4zagRxG4LbVue3xD+OAvlakmWBW7Lz8uL
6p9LpOcdxCPireOaRRMzcfWQjAj3PtjrVRhbUwsJHyQw9+puEFZfnOTeV14u
NFV4RPaXC9o/F8SNqLkdt9d4gSDMhY1+F0rktHxu293BNTn3GyPaX0nwePFw
f4hcpFrdQJMsgNEDNbMYwf+wi4a9kXhHqwJrnVtXiXIAOHcaG0XiJ8IFpe7O
kweb7a7rJC4bqGKQ76lsb5Sl+5Xtbqvd5fPjyfE3J5PnPVvr/QktvT5atH48
PxmdHMGBbdG6W+xPKlq3IobdJHT2V5wijAB1v2hD9sTjM6tGB3WzTOd2bo49
3JUJmQj/fFvrJ2d00JzC1unWVRmSh+iroc0OqO3eExLpamRuHOjv1LKyJHrT
2NEXEr/DAKLNhcTmNkKlHYZOR1GRo7FZT3YqgRNlzAya+dh9zgMykuXf7PxZ
F3Ta9jKBrwyye5B7N8HLXp+mg42aPhItcG2axn9t0/SLbZq++Y9t09T85NgU
WciWLvnXwoSI/tu3cXK3td3K6b9d26ZdSOy0bnLNjGxrjkbzuv0Bf+Zw9ifW
/rgmTPxu7Vxjb22b14ki3TQ/LVc4mBXXaBboNBZqDFIbxi44QGqd+Rje/GZM
decee/pfdtfwyMH/I16b1lmOjw7Y9g3zuIw+/8mgQZnlwBL/eGcMrOIZ7pOT
P8NwbwfAm2oES8g9O/8lT00ZDXDcQAiXjHQSjd3aWod92+5Fzl7fAeh4PDoZ
fQJIaVdJBhMBKulHL3bcnZ/o54L1HHBPzi7G/3nA3QdZsq+K2DoF9x9uB/wE
exn7ERzQ8XZwgEFpsljSfEF9hkJXIc3toTDFgGAWR1925mCiYZJB3QH++2/V
DNt0Y0h0FUtvOBe0hSP+Fn9jHe7yBMwR/Il68YTUv8yxlh8Yv4/5B0/gyrEN
5Uoe8VuKiwFXQHWNUkXUK2xS/T0YeGaq/A5E1G/Gq3gIKFnk/wIAw2p/5oQA
AA== [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.

In the html and pdf outputs, the text enclosed in <em> is output in
italics. In the txt output, the text enclosed in <em> appears with an
underscore before and after.

Please review carefully and let us know if the output is acceptable or if any
updates are needed.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not flag any terms or phrases.-->

</rfc>