<?xml version='1.0' 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.14 (Ruby 3.1.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-problem-details-08" version="3" category="std" consensus="true" submissionType="IETF" tocInclude="true" docName="draft-ietf-core-problem-details-08" indexInclude="true" ipr="trust200902" number="9290" prepTime="2022-10-18T15:04:38" scripts="Common,Hebrew,Latin" sortRefs="true" submissionType="IETF" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.0 --> tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-core-problem-details-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9290" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="CoRE Problem Details">Concise Problem Details For CoAP for Constrained Application Protocol (CoAP) APIs</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-core-problem-details-08"/> name="RFC" value="9290" stream="IETF"/>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>arm</organization>
      <organization showOnFrontPage="true">Arm Limited</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2022" month="July" day="06"/>
    <area>ART</area>
    <workgroup>CoRE Working Group</workgroup> month="10" year="2022"/>
    <area>art</area>
    <workgroup>core</workgroup>
    <keyword>CoAP</keyword>
    <keyword>API</keyword>
    <keyword>Problem Details</keyword>
    <keyword>CBOR Tag</keyword>
    <keyword>Language Tag</keyword>
    <keyword>Bidi</keyword>
    <abstract>
      <t>This
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a concise "problem detail" as a way to carry
machine-readable details of errors in a REST Representational State Transfer (REST) response to avoid the
need to define new error response formats for REST APIs for
constrained environments.
The format
is inspired by, but intended to be more concise than, the Problem
Details problem
details for HTTP APIs defined in RFC 7807.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Document</name>
      <t>
        Status information Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document document, any
            errata, and how to provide feedback on it may be found obtained at
            <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-problem-details/"/>. target="https://www.rfc-editor.org/info/rfc9290" brackets="none"/>.
        </t>
      <t>
        Discussion
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document takes place on must include Revised BSD License text as described in
            Section 4.e of the
        Constrained RESTful Environments Working Group mailing list (<eref target="mailto:core@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/"/>. Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      <t>Source for this draft
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-and-requirement">Terminology and an issue tracker can be found at
        <eref target="https://github.com/core-wg/core-problem-details"/>.</t>
    </note> Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-problem-details">Basic Problem Details</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extending-concise-problem-d">Extending Concise Problem Details</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-standard-problem-detail-ent">Standard Problem Detail Entries</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-standard-problem-detail-entr">Standard Problem Detail Entry: Unprocessed CoAP Option</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-custom-problem-detail-entri">Custom Problem Detail Entries</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-standard-problem-detail-key">Standard Problem Detail Keys Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-custom-problem-detail-keys-">Custom Problem Detail Keys Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type">Media Type</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-format">Content-Format</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-tag-38">CBOR Tag 38</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-language-tagged-strings">Language-Tagged Strings</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction-2">Introduction</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detailed-semantics">Detailed Semantics</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interworking-with-rfc-7807">Interworking with RFC 7807</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>REST anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">REST response status information such as CoAP Constrained Application Protocol (CoAP) response
codes (<xref section="5.9" sectionFormat="of" target="RFC7252"/>) target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.9" derivedContent="RFC7252"/>) is sometimes not sufficient to convey enough information about
an error to be helpful.  This specification defines a simple and extensible
framework to define CBOR Concise Binary Object Representation (CBOR) <xref target="STD94"/> target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/> data items to suit this purpose.
It
This framework is designed to be reused by REST APIs, which can identify distinct
"shapes" of these data items specific to their needs.
Thus, API clients can be informed of both the high-level error class
(using the response code) and the finer-grained details of the problem
(using the vocabulary defined here).
      This pattern of communication is illustrated in <xref target="fig-problem-details"/>.</t> target="fig-problem-details" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
      <figure anchor="fig-problem-details">
        <name>Problem anchor="fig-problem-details" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-problem-details-example-wit">Problem Details: Example with CoAP</name>
        <artset>
        <artset pn="section-1-2.1">
          <artwork type="svg" align="center"><svg align="center" pn="section-1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="288" viewBox="0 0 288 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
              <path d="M 48,80 L 48,240" fill="none" stroke="black"/>
              <path d="M 80,32 L 80,80" fill="none" stroke="black"/>
              <path d="M 168,32 L 168,80" fill="none" stroke="black"/>
              <path d="M 200,80 L 200,240" fill="none" stroke="black"/>
              <path d="M 240,32 L 240,80" fill="none" stroke="black"/>
              <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
              <path d="M 168,32 L 240,32" fill="none" stroke="black"/>
              <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
              <path d="M 168,80 L 240,80" fill="none" stroke="black"/>
              <path d="M 56,128 L 192,128" fill="none" stroke="black"/>
              <path d="M 56,160 L 192,160" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="200,128 188,122.4 188,133.6 " 188,133.6" fill="black" transform="rotate(0,192,128)"/>
              <polygon class="arrowhead" points="64,160 52,154.4 52,165.6 " 52,165.6" fill="black" transform="rotate(180,56,160)"/>
              <circle cx="48" cy="128" r="6" class="opendot" fill="white" stroke="black"/>
              <circle cx="200" cy="160" r="6" class="opendot" fill="white" stroke="black"/>
              <g class="text">
                <text x="44" y="52">CoAP</text>
                <text x="204" y="52">CoAP</text>
                <text x="44" y="68">Client</text>
                <text x="204" y="68">Server</text>
                <text x="88" y="116">Request</text>
                <text x="248" y="148">(failure)</text>
                <text x="96" y="180">Error</text>
                <text x="156" y="180">Response</text>
                <text x="116" y="196">with</text>
                <text x="144" y="196">a</text>
                <text x="172" y="196">CBOR</text>
                <text x="76" y="212">data</text>
                <text x="116" y="212">item</text>
                <text x="164" y="212">giving</text>
                <text x="96" y="228">Problem</text>
                <text x="160" y="228">Details</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[ align="center" pn="section-1-2.1.2">
.--------.          .--------.
|  CoAP  |          |  CoAP  |
| Client |          | Server |
'----+---'          '---+----'
     |                  |
     | Request          |
     o----------------->|
     o-----------------&gt;|
     |                  | (failure)
     |<-----------------o
     |&lt;-----------------o
     |   Error Response |
     |      with a CBOR |
     | data item giving |
     |  Problem Details |
     |                  |
]]></artwork>
</artwork>
        </artset>
      </figure>
      <t>The
      <t indent="0" pn="section-1-3">The framework presented is largely inspired by the Problem Details problem details for HTTP APIs defined in <xref target="RFC7807"/>. target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/>.
<xref target="comp7807"/> target="comp7807" format="default" sectionFormat="of" derivedContent="Appendix B"/> discusses applications where interworking with <xref target="RFC7807"/> target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/> is required.</t>
      <section anchor="terminology-and-requirements-language">
        <name>Terminology anchor="terminology-and-requirements-language" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology-and-requirement">Terminology and Requirements Language</name>
        <t>The
        <t indent="0" pn="section-1.1-1">The terminology from <xref target="RFC7252"/>, target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, <xref target="STD94"/>, target="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>, and <xref target="RFC8610"/> target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> applies; in particular particular, CBOR
diagnostic notation is defined in Section <xref section="8" sectionFormat="bare" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-8" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" target="STD94"/> derivedContent="STD94"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>. target="RFC8610" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/>.
Readers are also expected to be familiar with the terminology from <xref target="RFC7807"/>.</t>
        <t>In target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/>.</t>
        <t indent="0" pn="section-1.1-2">In this document, the structure of data is specified in CDDL Concise Data Definition Language (CDDL) <xref target="RFC8610"/> target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/> <xref target="RFC9165"/>.</t>
        <t>The target="RFC9165" format="default" sectionFormat="of" derivedContent="RFC9165"/>.</t>
        <t indent="0" pn="section-1.1-3">
    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 14 <xref target="RFC2119"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174"/> target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="basic">
      <name>Basic anchor="basic" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-basic-problem-details">Basic Problem Details</name>
      <t>A
      <t indent="0" pn="section-2-1">A Concise Problem Details data item is a CBOR data item with the following
structure (rules named starting with <tt>tag38</tt> are defined in <xref target="tag38"/>):</t> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>):</t>
      <figure anchor="cddl">
        <name>Structure anchor="cddl" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-structure-of-concise-proble">Structure of Concise Problem Details Data Item</name>
        <sourcecode type="cddl"><![CDATA[ type="cddl" markers="false" pn="section-2-2.1">
problem-details = non-empty<{ non-empty&lt;{
  ? &(title: &amp;(title: -1) => =&gt; oltext
  ? &(detail: &amp;(detail: -2) => =&gt; oltext
  ? &(instance: &amp;(instance: -3) => =&gt; ~uri
  ? &(response-code: &amp;(response-code: -4) => =&gt; uint .size 1
  ? &(base-uri: &amp;(base-uri: -5) => =&gt; ~uri
  ? &(base-lang: &amp;(base-lang: -6) => =&gt; tag38-ltag
  ? &(base-rtl: &amp;(base-rtl: -7) => =&gt; tag38-direction
  standard-problem-detail-entries
  custom-problem-detail-entries
}>
}&gt;

standard-problem-detail-entries = (
  * nint => =&gt; any
)

custom-problem-detail-entries = (
  * (uint/~uri) => =&gt; { + any => =&gt; any }
)

non-empty<M>

non-empty&lt;M&gt; = (M) .and ({ + any => =&gt; any })

oltext = text / tag38

]]></sourcecode>

</sourcecode>
      </figure>
      <t>(Examples
      <t indent="0" pn="section-2-3">(Examples of elaborated Concise Problem Details data items can
be found later in the document, e.g., <xref target="fig-example-custom-with-uri"/>.)</t>
      <t>A target="fig-example-custom-with-uri" format="default" sectionFormat="of" derivedContent="Figure 3"/>.)</t>
      <t indent="0" pn="section-2-4">A number of problem detail entries, the Standard Problem Detail
entries, are predefined (more predefined details can be registered,
see <xref target="new-spdk"/>).</t>
      <t>Note target="new-spdk" format="default" sectionFormat="of" derivedContent="Section 3.1"/>).</t>
      <t indent="0" pn="section-2-5">Note that, unlike <xref target="RFC7807"/>, target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/>, Concise Problem Details data items have
no explicit "problem type".
Instead, the category (or, one could say, Gestalt) of the problem can
be understood from the shape of the problem details offered. We talk of
a "problem shape" for short.</t>
      <dl newline="true">
        <dt>The newline="true" indent="3" spacing="normal" pn="section-2-6">
        <dt pn="section-2-6.1">The title (key -1):</dt>
        <dd>
          <t>A
        <dd pn="section-2-6.2">
          <t indent="0" pn="section-2-6.2.1">A short, human-readable summary of the problem shape.
Beyond the shape of the problem, it is not intended to summarize all
the specific information given with the problem details.
For instance, the summary might include that an account does not
have enough money for a transaction to succeed, succeed but not the detail detailed
information such as the account number, how much money that account
has, and how much would be needed.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.3">The detail (key -2):</dt>
        <dd>
          <t>A
        <dd pn="section-2-6.4">
          <t indent="0" pn="section-2-6.4.1">A human-readable explanation specific to this occurrence of the problem.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.5">The instance (key -3):</dt>
        <dd>
          <t>A
        <dd pn="section-2-6.6">
          <t indent="0" pn="section-2-6.6.1">A URI reference that identifies the specific occurrence of the problem.
It may or may not yield further information if dereferenced.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.7">The response-code (key -4):</dt>
        <dd>
          <t>The
        <dd pn="section-2-6.8">
          <t indent="0" pn="section-2-6.8.1">The CoAP response code (Sections <xref target="RFC7252" section="5.9" sectionFormat="bare"/> sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.9" derivedContent="RFC7252"/> and <xref target="RFC7252" section="12.1.2" sectionFormat="bare"/> sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-12.1.2" derivedContent="RFC7252"/> of <xref target="RFC7252"/>) target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>) generated by the origin
server for this occurrence of the problem.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.9">The base-uri (key -5):</dt>
        <dd>
          <t>The
        <dd pn="section-2-6.10">
          <t indent="0" pn="section-2-6.10.1">The base URI (<xref (see Section <xref section="5.1" sectionFormat="bare" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-5.1" derivedContent="RFC3986"/> of RFC 3986 <xref target="STD66" format="default" sectionFormat="of" target="STD66"/>) derivedContent="STD66"/>) that should be used to resolve
relative URI references embedded in this Concise Problem Details
data item.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.11">The base-lang (key -6):</dt>
        <dd>
          <t>The
        <dd pn="section-2-6.12">
          <t indent="0" pn="section-2-6.12.1">The language-tag (tag38-ltag) that applies to the presentation of
unadorned text strings (not using tag 38) in this Concise Problem
Details data item, item; see <xref target="tag38"/>.</t> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
        </dd>
        <dt>The
        <dt pn="section-2-6.13">The base-rtl (key -7):</dt>
        <dd>
          <t>The
        <dd pn="section-2-6.14">
          <t indent="0" pn="section-2-6.14.1">The writing-direction (tag38-direction) that applies to the
presentation of unadorned text strings (not using tag 38) in this
Concise Problem Details data item, item; see <xref target="tag38"/>.</t> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
        </dd>
      </dl>
      <t>Both
      <t indent="0" pn="section-2-7">Both "title" and "detail" can use either an unadorned CBOR text string
(<tt>text</tt>) or a language-tagged text string (<tt>tag38</tt>); see <xref target="tag38"/> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/> for
the definition of the latter.
Language tag and writing direction information for unadorned text
strings are is intended to be obtained from context; if that context
needs to be saved or forwarded with a Concise Problem Details data
item, "base-lang" and "base-rtl" can be used for that. used.
If no such (explicitly saved or implicit) context information is
available, unadorned text is interpreted with language-tag "en" and
writing-direction "false" (ltr).</t>
      <t>The
      <t indent="0" pn="section-2-8">The "title" string is advisory and included to give
consumers a shorthand for the category (problem shape) of the error encountered.</t>
      <t>The
      <t indent="0" pn="section-2-9">The "detail" member, if present, ought to focus on helping the client
correct the problem, problem rather than giving extensive server-side
debugging information.
Consumers <bcp14>SHOULD NOT</bcp14> parse the "detail" member for information;
extensions (see <xref target="sec-new-attributes"/>) target="sec-new-attributes" format="default" sectionFormat="of" derivedContent="Section 3"/>) are more suitable and less
error-prone ways to obtain such information.
Note that the "instance" URI reference may be relative; this means
that it must be resolved relative to the representation's base URI, as
per Section <xref section="5" sectionFormat="bare" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-5" derivedContent="RFC3986"/> of RFC 3986 <xref target="STD66" format="default" sectionFormat="of" target="STD66"/>.</t>
      <t>The derivedContent="STD66"/>.</t>
      <t indent="0" pn="section-2-10">The "response-code" member, if present, is only advisory; it conveys
the CoAP response code used for the convenience of the consumer.
Generators <bcp14>MUST</bcp14> use the same response code here as in the actual CoAP
response; the latter is needed to assure that generic CoAP software that
does not understand the problem-details format still behaves
correctly.
Consumers can use the response-code "response-code" member to determine what the
original response code used by the generator was, in cases where it
has been changed (e.g., by an intermediary or cache), and when message
bodies persist without CoAP information (e.g., in an events log or analytics
database).
Generic CoAP software will still use the CoAP response code.
To support the use case of message body message-body persistence without support by
the problem-details generator, the entity that persists the Concise
Problem Details data item can copy over the CoAP response code
that it received on the CoAP level.
Note that the "response-code" value is a numeric representation of the
actual code (see <xref section="3" sectionFormat="of" target="RFC7252"/>), target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-3" derivedContent="RFC7252"/>), so it does not take the usual
presentation form that resembles an
HTTP status code -- code: <tt>4.04 Not found</tt> Found</tt> is represented by the number 132.</t>
      <t>The
      <t indent="0" pn="section-2-11">The "base-uri" member is usually not present in the initial
request-response communication as it can be inferred as per Section <xref section="5.1.3" sectionFormat="bare" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-5.1.3" derivedContent="RFC3986"/> of RFC 3986 <xref target="STD66" format="default" sectionFormat="of" target="STD66"/>. derivedContent="STD66"/>.
An entity that stores a Concise Problem Details data item or otherwise
makes it available for consumers without this context might add in a
base-uri
"base-uri" member to allow those consumers to perform resolution of any
relative URI references embedded in the data item.</t>
    </section>
    <section anchor="sec-new-attributes">
      <name>Extending anchor="sec-new-attributes" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-extending-concise-problem-d">Extending Concise Problem Details</name>
      <t>This
      <t indent="0" pn="section-3-1">This specification defines a generic problem details problem-details container with only a
minimal set of attributes to make it usable.</t>
      <t>It
      <t indent="0" pn="section-3-2">It is expected that applications will extend the base format by defining new
attributes.</t>
      <t>These
      <t indent="0" pn="section-3-3">These new attributes fall into two categories: generic and application
specific.</t>
      <t>Generic
      <t indent="0" pn="section-3-4">Generic attributes will be allocated in the <tt>standard-problem-detail-entries</tt>
slot according to the registration procedure defined in <xref target="new-spdk"/>.</t>
      <t>Application-specific target="new-spdk" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</t>
      <t indent="0" pn="section-3-5">Application-specific attributes will be allocated in the
<tt>custom-problem-detail-entries</tt> slot according to the procedure described in
<xref target="new-cpdk"/>.</t> target="new-cpdk" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</t>
      <t anchor="ignore-unknown">Consumers anchor="ignore-unknown" indent="0" pn="section-3-6">Consumers of a Concise Problem Details data item <bcp14>MUST</bcp14> ignore any
Standard Problem Detail entries or Custom Problem Detail entries, or keys inside the Custom
Problem Detail entries, that they do not recognize ("ignore-unknown
rule"); this allows problem details to evolve.  When storing the data item for future use or forwarding it to other
consumers, it is strongly <bcp14>RECOMMENDED</bcp14> to retain the unrecognized
entries; exceptions might be when storage/forwarding storage or forwarding occurs in a
different format/protocol that cannot accommodate them, them or when the
storage/forwarding
storage or forwarding function needs to filter out privacy-sensitive
information and for that needs to assume unrecognized entries might be
privacy-sensitive.</t>
      <section anchor="new-spdk">
        <name>Standard anchor="new-spdk" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-standard-problem-detail-ent">Standard Problem Detail Entries</name>
        <t>Beyond
        <t indent="0" pn="section-3.1-1">Beyond the Standard Problem Detail keys defined in <xref target="cddl"/>, target="cddl" format="default" sectionFormat="of" derivedContent="Figure 2"/>, additional
Standard Problem Detail keys can be registered for use in the
<tt>standard-problem-detail-entries</tt> slot (see <xref target="iana-spdk"/>).</t>
        <t>Standard target="iana-spdk" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).</t>
        <t indent="0" pn="section-3.1-2">Standard Problem Detail keys are negative integers, so they can never
conflict with Custom Problem Detail keys defined for a specific
application domain
(which are unsigned integers or URIs.)</t>
        <t>In
        <t indent="0" pn="section-3.1-3">In summary, the keys for Standard Problem Detail entries are in a
global namespace that is not specific to a particular application domain.</t>
        <section anchor="uco">
          <name>Standard anchor="uco" numbered="true" removeInRFC="false" toc="include" pn="section-3.1.1">
          <name slugifiedName="name-standard-problem-detail-entr">Standard Problem Detail Entry: Unprocessed CoAP Option</name>
          <t><xref target="basic"/>
          <t indent="0" pn="section-3.1.1-1"><xref target="basic" format="default" sectionFormat="of" derivedContent="Section 2"/> provides a number of generally applicable Standard Problem
Detail Entries. entries.  The present section both registers another useful
Standard Problem Detail entry and serves as an example of a Standard
Problem Detail Entry registration, in the registration template format
that would be ready for registration.</t>
          <blockquote>
            <dl>
              <dt>Key Value:</dt>
              <dd>
                <t>TBD (assigned at registration)</t>
          <dl newline="true" spacing="compact" indent="3" pn="section-3.1.1-2">
            <dt pn="section-3.1.1-2.1">Key value:</dt>
            <dd pn="section-3.1.1-2.2">
              <t indent="0" pn="section-3.1.1-2.2.1">-8</t>
            </dd>
              <dt>Name:</dt>
              <dd>
                <t>unprocessed-coap-option</t>
            <dt pn="section-3.1.1-2.3">Name:</dt>
            <dd pn="section-3.1.1-2.4">
              <t indent="0" pn="section-3.1.1-2.4.1">unprocessed-coap-option</t>
            </dd>
              <dt>CDDL
            <dt pn="section-3.1.1-2.5">CDDL type:</dt>
              <dd>
                <t><tt>one-or-more&lt;uint&gt;</tt>,
            <dd pn="section-3.1.1-2.6">
              <t indent="0" pn="section-3.1.1-2.6.1"><tt>one-or-more&lt;uint&gt;</tt>, where
</t>
                <artwork><![CDATA[
one-or-more<T>
              <sourcecode type="" markers="false" pn="section-3.1.1-2.6.2">
one-or-more&lt;T&gt; = T / [ 2* T ]
]]></artwork>
</sourcecode>
            </dd>
              <dt>Brief
            <dt pn="section-3.1.1-2.7">Brief description:</dt>
              <dd>
                <t>Option
            <dd pn="section-3.1.1-2.8">
              <t indent="0" pn="section-3.1.1-2.8.1">Option number(s) of CoAP option(s) that were not understood</t>
            </dd>
              <dt>Specification
            <dt pn="section-3.1.1-2.9">Specification reference:</dt>
              <dd>
                <t><xref target="uco"/>
            <dd pn="section-3.1.1-2.10">
              <t indent="0" pn="section-3.1.1-2.10.1"><xref target="uco" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/> of RFC XXXX</t> 9290</t>
            </dd>
          </dl>
          </blockquote>
          <t><cref anchor="to-be-removed">RFC Editor: please replace RFC XXXX with the RFC
number of this RFC and remove this note.</cref></t>
          <t>The
          <t indent="0" pn="section-3.1.1-3">The specification of the Standard Problem Detail entry referenced by
the above registration template follows:</t>
          <t>The
          <t indent="0" pn="section-3.1.1-4">The Standard Problem Detail entry <tt>unprocessed-coap-option</tt> provides
the option number(s) number or numbers of any CoAP option(s) options present in the request that
could not be processed by the server.</t>
          <t>This
          <t indent="0" pn="section-3.1.1-5">This may be a critical option that the server is unaware of, or an
option the server is aware of but could not process (and chose not
to, or was not allowed to, ignore it).</t>
          <t>The
          <t indent="0" pn="section-3.1.1-6">The Concise Problem Details data item including this Standard
Problem Detail Entry can be used in fulfillment of the "<bcp14>SHOULD</bcp14>"
requirement in <xref section="5.4.1" sectionFormat="of" target="RFC7252"/>.</t>
          <t>Several target="RFC7252" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.4.1" derivedContent="RFC7252"/>.</t>
          <t indent="0" pn="section-3.1.1-7">Several option numbers may be given in a list (in no particular order),
without any guarantee that the list is a complete representation of
all the problems in the request (as the server might
have stopped processing already at one of the problematic options).
If an option with the given number was repeated, there is no
indication which of the values caused the error.</t>
          <t>Clients
          <t indent="0" pn="section-3.1.1-8">Clients need to expect seeing to see options in the list that they did not send
in the request; this can happen if the request traversed a proxy
that added the option but did not act on the problem details problem-details
response being returned by the origin server.</t>
          <t>Note that for
          <t indent="0" pn="section-3.1.1-9">For a few special values of unprocessed CoAP
options (such as Accept or Proxy-Uri), note that there are special response
codes (4.06 Not Acceptable, 5.05 Proxying Not Supported,
respectively) to be sent instead of 4.02 Bad Option.</t>
        </section>
      </section>
      <section anchor="new-cpdk">
        <name>Custom anchor="new-cpdk" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-custom-problem-detail-entri">Custom Problem Detail Entries</name>
        <t>Applications
        <t indent="0" pn="section-3.2-1">Applications may extend the Concise Problem Details data item with
additional entries to convey additional, application-specific information.</t>
        <t>Such
        <t indent="0" pn="section-3.2-2">Such new entries are allocated in the <tt>custom-problem-detail-entries</tt> slot, slot and
carry a nested map specific to that application.  The map key can either be either
an (absolute!) URI (under control of the entity defining this extension), extension)
or an unsigned integer.
Only the latter needs to be registered (<xref target="iana-cpdk"/>).</t>
        <t>Within target="iana-cpdk" format="default" sectionFormat="of" derivedContent="Section 6.2"/>).</t>
        <t indent="0" pn="section-3.2-3">Within the nested map, any number of attributes can be given for a
single extension.
The semantics of each custom attribute <bcp14>MUST</bcp14> be described in the
documentation for the extension; for extensions that are registered
(i.e., are identified by an unsigned int) int), that documentation goes
along with the registration.</t>
        <t>The
        <t indent="0" pn="section-3.2-4">The unsigned integer form allows a more compact representation.
In
exchange, authors are expected to comply with the required
registration and documentation process.
In comparison, the URI form is less space-efficient space efficient but requires no
registration.  It  Therefore, it is therefore useful for experimenting during the development
cycle and for applications deployed in environments where producers and
consumers of Concise Problem Details are more tightly integrated.
(The
(Thus, the URI form thus covers the potential need we might otherwise have for a "private use" "Private Use" range for the unsigned integers.)</t>
        <t anchor="no-dereference">Note anchor="no-dereference" indent="0" pn="section-3.2-5">Note that the URI given for the extension is for identification
purposes only and, even if dereferenceable in principle, it <bcp14>MUST NOT</bcp14> be
dereferenced in the normal course of handling problem details (i.e., outside
diagnostic/debugging
diagnostic or debugging procedures involving humans).</t>
        <t><xref target="fig-example-custom-with-uri"/>
        <t indent="0" pn="section-3.2-6"><xref target="fig-example-custom-with-uri" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an example (in CBOR diagnostic notation)
of a custom extension using a (made-up) URI as the <tt>custom-problem-detail-entries</tt> key.</t>
        <figure anchor="fig-example-custom-with-uri">
          <name>Example anchor="fig-example-custom-with-uri" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-example-extension-with-uri-">Example Extension with URI key</name>
          <artwork Key</name>
          <sourcecode type="cbor-diag" align="center"><![CDATA[ markers="false" pn="section-3.2-7.1">
{
  / title /         -1: "title of the error",
  / detail /        -2: "detailed information about the error",
  / instance /      -3: "coaps://pd.example/FA317434",
  / response-code / -4: 128, / 4.00 /

  "tag:3gpp.org,2022-03:TS29112": {
    / cause /  0: "machine-readable error cause",
    / invalidParams / 1: [
      [
        / param / "first parameter name",
        / reason / "must be a positive integer"
      ],
      [
        / param / "second parameter name"
      ]
    ],
    / supportedFeatures / 2: "d34db33f"
  }
}
]]></artwork>
</sourcecode>
        </figure>
        <t>Obviously, an SDO
        <t indent="0" pn="section-3.2-8">Obviously, a Standards Development Organization (SDO) like 3GPP can also easily register such a custom
problem detail Custom
Problem Detail entry to receive a more efficient unsigned integer key;
<xref target="fig-example-custom-with-uint"/> target="fig-example-custom-with-uint" format="default" sectionFormat="of" derivedContent="Figure 4"/> shows how
the same example would look like using a (made-up) registered unsigned int as the
<tt>custom-problem-detail-entries</tt> key:</t>
        <figure anchor="fig-example-custom-with-uint">
          <name>Example anchor="fig-example-custom-with-uint" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-extension-with-unsi">Example Extension with unsigned int (registered) key</name>
          <artwork Unsigned Int (Registered) Key</name>
          <sourcecode type="cbor-diag" align="center"><![CDATA[ markers="false" pn="section-3.2-9.1">
{
  / title /         -1: "title of the error",
  / detail /        -2: "detailed information about the error",
  / instance /      -3: "coaps://pd.example/FA317434",
  / response-code / -4: 128, / 4.00 /

  /4711 is made-up example key that is not actually registered:/
  4711: {
    / cause /  0: "machine-readable error cause",
    / invalidParams / 1: [
      [
        / param / "first parameter name",
        / reason / "must be a positive integer"
      ],
      [
        / param / "second parameter name"
      ]
    ],
    / supportedFeatures / 2: "d34db33f"
  }
}
]]></artwork>
</sourcecode>
        </figure>
        <t>In
        <t indent="0" pn="section-3.2-10">In summary, the keys for the maps used inside Custom Problem Detail
entries are defined specifically to for use with the identifier of that Custom
Problem Detail entry, the documentation of which defines these
internal entries, typically chosen to address a given application
domain.</t>
        <t>When
        <t indent="0" pn="section-3.2-11">When there is a need to evolve a Custom Problem Detail entry definition, the
"ignore-unknown rule" discussed in the introduction to <xref target="sec-new-attributes"/> target="sec-new-attributes" format="default" sectionFormat="of" derivedContent="Section 3"/> provides an easy way to include additional information.
The assumption is that this is done in a backward backward- and forward
compatible forward-compatible way.
Sometimes, Custom Problem Detail entries may need to evolve in a way where
forward compatibility by applying the "ignore-unknown rule" would not
be appropriate: e.g., for example, when adding a "must-understand" member,
which can only
be ignored at the peril of misunderstanding the Concise Problem
Details data item ("false interoperability").
In this case, a new Custom Problem Detail key can simply be
registered for this case, keeping the old key backward and
forward compatible.</t>
      </section>
    </section>
    <section anchor="privcons">
      <name>Privacy anchor="privcons" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t>Problem
      <t indent="0" pn="section-4-1">Problem details may unintentionally disclose information.
This can lead to both privacy and security problems.
See <xref target="seccons"/> target="seccons" format="default" sectionFormat="of" derivedContent="Section 5"/> for more details that apply to both domains; particular
attention needs to be given to unintentionally disclosing Personally
Identifiable Information (PII).</t>
    </section>
    <section anchor="seccons">
      <name>Security anchor="seccons" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t>Concise
      <t indent="0" pn="section-5-1">Concise Problem Details can contain URIs that are not intended to be
dereferenced (<xref target="no-dereference"/>). target="no-dereference" format="default" sectionFormat="of" derivedContent="Section 3.2, Paragraph 5"/>).  One reason is that dereferencing
these can lead to information disclosure (tracking).
Information disclosure can also be caused by URIs in problem details
that <em>are</em> intended for dereferencing, e.g., the "instance" URI.
Implementations need to consider which component of a client should
perform the dereferencing, dereferencing and which servers are trusted with serving
them.
In any case, the security considerations of Section <xref section="7" sectionFormat="bare" target="RFC3986" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-7" derivedContent="RFC3986"/> of RFC 3986 <xref target="STD66" format="default" sectionFormat="of" target="STD66"/> derivedContent="STD66"/> apply.</t>
      <t>The
      <t indent="0" pn="section-5-2">The security and privacy considerations outlined in <xref section="5" sectionFormat="of" target="RFC7807"/> target="RFC7807" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7807#section-5" derivedContent="RFC7807"/> apply in full.

While these are phrased in terms of security considerations for new RFC 7807 problem types, they equally apply to the problem detail
entry definitions used here <xref target="sec-new-attributes"/>; in summary: (<xref target="sec-new-attributes" format="default" sectionFormat="of" derivedContent="Section 3"/>). In summary, both
when defining new detail entries, entries and when actually generating using them to generate a
Concise Problem Details data item, care needs to be taken that they do
not leak sensitive information.
Entities storing or forwarding Concise Problem Details data items need
to consider whether this leads to information being transferred out of
the context within which access to sensitive information was acceptable.
See also <xref target="ignore-unknown"/> target="ignore-unknown" format="default" sectionFormat="of" derivedContent="Section 3, Paragraph 6"/> (the last paragraph of the introduction to
that section).
Privacy-sensitive information in the problem details <bcp14>SHOULD NOT</bcp14> be obscured in ways that might lead to misclassification as
non-sensitive (e.g., by base64-encoding).</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t><cref anchor="to-be-removed_1">RFC Editor: please replace RFC XXXX with the RFC
number of this RFC and remove this note.</cref></t>
      <section anchor="iana-spdk">
        <name>Standard anchor="iana-spdk" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-standard-problem-detail-key">Standard Problem Detail Key registry</name>
        <!-- {{content-formats (CoAP Content-Formats)<IANA.core-parameters}} -->

<t>This Keys Registry</name>
        <t indent="0" pn="section-6.1-1">This specification defines a new sub-registry for Standard subregistry titled "Standard Problem
Detail Keys Keys" in the CoRE Parameters "Constrained RESTful Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>, target="IANA.core-parameters" format="default" sectionFormat="of" derivedContent="IANA.core-parameters"/>,
with "Specification Required" as the policy "specification required" Registration Procedure (<xref section="4.6" sectionFormat="of" target="RFC8126"/>).</t>
        <t>Each target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/>).</t>
        <t indent="0" pn="section-6.1-2">Each entry in the registry must include:</t>
        <dl newline="true">
          <dt>Key value:</dt>
          <dd>
            <t>a newline="true" indent="3" spacing="normal" pn="section-6.1-3">
          <dt pn="section-6.1-3.1">Key Value:</dt>
          <dd pn="section-6.1-3.2">
            <t indent="0" pn="section-6.1-3.2.1">a negative integer to be used as the value of the key</t>
          </dd>
          <dt>Name:</dt>
          <dd>
            <t>a
          <dt pn="section-6.1-3.3">Name:</dt>
          <dd pn="section-6.1-3.4">
            <t indent="0" pn="section-6.1-3.4.1">a name that could be used in implementations for the key</t>
          </dd>
          <dt>CDDL type:</dt>
          <dd>
            <t>type
          <dt pn="section-6.1-3.5">CDDL Type:</dt>
          <dd pn="section-6.1-3.6">
            <t indent="0" pn="section-6.1-3.6.1">type of the data associated with the key in CDDL notation</t>
          </dd>
          <dt>Brief description:</dt>
          <dd>
            <t>a
          <dt pn="section-6.1-3.7">Brief Description:</dt>
          <dd pn="section-6.1-3.8">
            <t indent="0" pn="section-6.1-3.8.1">a brief description</t>
          </dd>
          <dt>Change
          <dt pn="section-6.1-3.9">Reference:</dt>
          <dd pn="section-6.1-3.10">
            <t indent="0" pn="section-6.1-3.10.1">a reference document</t>
          </dd>
          <dt pn="section-6.1-3.11">Change Controller:</dt>
          <dd>
            <t>(see
          <dd pn="section-6.1-3.12">
            <t indent="0" pn="section-6.1-3.12.1">(see <xref section="2.3" sectionFormat="of" target="RFC8126"/>)</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>a reference document</t> target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-2.3" derivedContent="RFC8126"/>)</t>
          </dd>
        </dl>
        <t>The
        <t indent="0" pn="section-6.1-4">The designated expert is requested to assign the shortest key values (1+0 and
1+1 encoding) to registrations that are likely to enjoy wide use and
can benefit from short encodings.</t>
        <t>To
        <t indent="0" pn="section-6.1-5">To be immediately useful in CDDL and programming language programming-language contexts, a
name consists of a lower-case lowercase ASCII letter (a-z) and zero or more
additional ASCII characters that are either lower-case lowercase letters,
digits, or a hyphen-minus, i.e., it matches <tt>[a-z][-a-z0-9]*</tt>.
As with the key values, names need to be unique.</t>
        <t>The
        <t indent="0" pn="section-6.1-6">The specification in the reference document needs to provide a
description of the Standard Problem Detail entry, replicating the CDDL
description in "CDDL type", Type", and describing the semantics of the
presence of this entry and the semantics of the value given with it.</t>
        <t>Initial
        <t indent="0" pn="section-6.1-7">Initial entries in this sub-registry subregistry are as follows:</t>
        <table anchor="spdk">
          <name>Initial anchor="spdk" align="center" pn="table-1">
          <name slugifiedName="name-initial-entries-in-the-stan">Initial Entries in the Standard Problem Detail Key registry</name> Keys Registry</name>
          <thead>
            <tr>
              <th align="left">Key value</th> align="left" colspan="1" rowspan="1">Key Value</th>
              <th align="left">Name</th> align="left" colspan="1" rowspan="1">Name</th>
              <th align="left">CDDL align="left" colspan="1" rowspan="1">CDDL Type</th>
              <th align="left">Brief description</th> align="left" colspan="1" rowspan="1">Brief Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
              <th align="left">Reference</th> align="left" colspan="1" rowspan="1">Change Controller</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">-1</td> align="left" colspan="1" rowspan="1">-1</td>
              <td align="left">title</td> align="left" colspan="1" rowspan="1">title</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>text / tag38</tt></td>
              <td align="left">short, align="left" colspan="1" rowspan="1">Short, human-readable summary of the problem shape</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-2</td> align="left" colspan="1" rowspan="1">-2</td>
              <td align="left">detail</td> align="left" colspan="1" rowspan="1">detail</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>text / tag38</tt></td>
              <td align="left">human-readable align="left" colspan="1" rowspan="1">Human-readable explanation specific to this occurrence of the problem</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-3</td> align="left" colspan="1" rowspan="1">-3</td>
              <td align="left">instance</td> align="left" colspan="1" rowspan="1">instance</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>~uri</tt></td>
              <td align="left">URI align="left" colspan="1" rowspan="1">URI reference identifying specific occurrence of the problem</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-4</td> align="left" colspan="1" rowspan="1">-4</td>
              <td align="left">response-code</td> align="left" colspan="1" rowspan="1">response-code</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>uint .size 1</tt></td>
              <td align="left">CoAP align="left" colspan="1" rowspan="1">CoAP response code</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-5</td> align="left" colspan="1" rowspan="1">-5</td>
              <td align="left">base-uri</td> align="left" colspan="1" rowspan="1">base-uri</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>~uri</tt></td>
              <td align="left">Base align="left" colspan="1" rowspan="1">Base URI</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-6</td> align="left" colspan="1" rowspan="1">-6</td>
              <td align="left">base-lang</td> align="left" colspan="1" rowspan="1">base-lang</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>tag38-ltag</tt></td>
              <td align="left">Base align="left" colspan="1" rowspan="1">Base language tag (see <xref target="tag38"/>)</td> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>)</td>
              <td align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">-7</td> align="left" colspan="1" rowspan="1">-7</td>
              <td align="left">base-rtl</td> align="left" colspan="1" rowspan="1">base-rtl</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>tag38-direction</tt></td>
              <td align="left">Base align="left" colspan="1" rowspan="1">Base writing direction (see <xref target="tag38"/>)</td> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>)</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
            <tr>
              <td align="left">TBD</td> align="left" colspan="1" rowspan="1">-8</td>
              <td align="left">unprocessed-coap-option</td> align="left" colspan="1" rowspan="1">unprocessed-coap-option</td>
              <td align="left"> align="left" colspan="1" rowspan="1">
                <tt>one-or-more&lt;uint&gt;</tt></td>
              <td align="left">Option align="left" colspan="1" rowspan="1">Option number(s) of CoAP option(s) that were not understood</td>
              <td align="left">RFC XXXX, align="left" colspan="1" rowspan="1">RFC 9290, <xref target="uco"/></td> target="uco" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/></td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="iana-cpdk">
        <name>Custom anchor="iana-cpdk" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-custom-problem-detail-keys-">Custom Problem Detail Key registry</name>
        <t>This Keys Registry</name>
        <t indent="0" pn="section-6.2-1">This specification defines a new sub-registry for Custom subregistry titled "Custom Problem
Detail Keys Keys" in the CoRE Parameters "Constrained RESTful Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>, target="IANA.core-parameters" format="default" sectionFormat="of" derivedContent="IANA.core-parameters"/>,
	with as "Expert Review" as the policy "expert review" Registration Procedure (<xref section="4.5" sectionFormat="of" target="RFC8126"/>).</t>
        <t>The target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.5" derivedContent="RFC8126"/>).</t>
        <t indent="0" pn="section-6.2-2">The designated expert is instructed to attempt making the registration experience
as close to first-come-first-served First Come First Served as reasonably achievable, but
checking that the reference document does provide a description as set
out below.
(This requirement is a relaxed version of "specification required" "Specification Required" as
defined in <xref section="4.6" sectionFormat="of" target="RFC8126"/>.)</t>
        <t>Each target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/>.)</t>
        <t indent="0" pn="section-6.2-3">Each entry in the registry must include:</t>
        <dl newline="true">
          <dt>Key value:</dt>
          <dd>
            <t>an newline="true" indent="3" spacing="normal" pn="section-6.2-4">
          <dt pn="section-6.2-4.1">Key Value:</dt>
          <dd pn="section-6.2-4.2">
            <t indent="0" pn="section-6.2-4.2.1">an unsigned integer to be used as the value of the key</t>
          </dd>
          <dt>Name:</dt>
          <dd>
            <t>a
          <dt pn="section-6.2-4.3">Name:</dt>
          <dd pn="section-6.2-4.4">
            <t indent="0" pn="section-6.2-4.4.1">a name that could be used in implementations for the key</t>
          </dd>
          <dt>Brief description:</dt>
          <dd>
            <t>a
          <dt pn="section-6.2-4.5">Brief Description:</dt>
          <dd pn="section-6.2-4.6">
            <t indent="0" pn="section-6.2-4.6.1">a brief description</t>
          </dd>
          <dt>Change Controller:</dt>
          <dd>
            <t>(see <xref section="2.3" sectionFormat="of" target="RFC8126"/>)</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t>a
          <dt pn="section-6.2-4.7">Reference:</dt>
          <dd pn="section-6.2-4.8">
            <t indent="0" pn="section-6.2-4.8.1">a reference document that provides a description of the map,
including a CDDL description, that describes all inside keys and
values</t>
          </dd>
          <dt pn="section-6.2-4.9">Change Controller</dt>
          <dd pn="section-6.2-4.10">
            <t indent="0" pn="section-6.2-4.10.1">(see <xref section="2.3" sectionFormat="of" target="RFC8126" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-2.3" derivedContent="RFC8126"/>)</t>
          </dd>
        </dl>
        <t>The
        <t indent="0" pn="section-6.2-5">The designated expert is requested to assign the shortest key values (1+0 and
1+1 encoding) to registrations that are likely to enjoy wide use and
can benefit from short encodings.</t>
        <t>To
        <t indent="0" pn="section-6.2-6">To be immediately useful in CDDL and programming language programming-language contexts, a
name consists of a lower-case lowercase ASCII letter (a-z) and zero or more
additional ASCII characters that are either lower-case lowercase letters,
digits, or a hyphen-minus, i.e., it matches <tt>[a-z][-a-z0-9]*</tt>.
As with the key values, names need to be unique.</t>
        <t>Initial
        <t indent="0" pn="section-6.2-7">Initial entries in this sub-registry subregistry are as follows:</t>
        <table anchor="cpdk">
          <name>Initial anchor="cpdk" align="center" pn="table-2">
          <name slugifiedName="name-initial-entries-in-the-cust">Initial Entries in the Custom Problem Detail Key registry</name> Registry</name>
          <thead>
            <tr>
              <th align="left">Key value</th> align="left" colspan="1" rowspan="1">Key Value</th>
              <th align="left" colspan="1" rowspan="1">Name</th>
              <th align="left">Name</th> align="left" colspan="1" rowspan="1">Brief Description</th>
              <th align="left">Brief description</th> align="left" colspan="1" rowspan="1">Reference</th>
              <th align="left">Reference</th> align="left" colspan="1" rowspan="1">Change Controller</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">7807</td> align="left" colspan="1" rowspan="1">7807</td>
              <td align="left">tunnel-7807</td> align="left" colspan="1" rowspan="1">tunnel-7807</td>
              <td align="left">Carry align="left" colspan="1" rowspan="1">Carry RFC 7807 problem details in a Concise Problem Details data item</td>
              <td align="left">RFC XXXX, align="left" colspan="1" rowspan="1">RFC 9290, <xref target="comp7807"/></td> target="comp7807" format="default" sectionFormat="of" derivedContent="Appendix B"/></td>
              <td align="left" colspan="1" rowspan="1">IETF</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="media-type">
        <name>Media anchor="media-type" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-media-type">Media Type</name>
        <t>IANA is requested to add
        <t indent="0" pn="section-6.3-1">IANA has added the following Media-Type media type to the "Media Types"
registry <xref target="IANA.media-types"/>.</t> target="IANA.media-types" format="default" sectionFormat="of" derivedContent="IANA.media-types"/>.</t>
        <table align="left" anchor="new-media-type">
          <name>New anchor="new-media-type" pn="table-3">
          <name slugifiedName="name-new-media-type-application-">New Media Type application/concise-problem-details+cbor</name> 'application/concise-problem-details+cbor'</name>
          <thead>
            <tr>
              <th align="left">Name</th> align="left" colspan="1" rowspan="1">Name</th>
              <th align="left">Template</th> align="left" colspan="1" rowspan="1">Template</th>
              <th align="left">Reference</th> align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">concise-problem-details+cbor</td> align="left" colspan="1" rowspan="1">concise-problem-details+cbor</td>
              <td align="left">application/concise-problem-details+cbor</td> align="left" colspan="1" rowspan="1">application/concise-problem-details+cbor</td>
              <td align="left">RFC XXXX, align="left" colspan="1" rowspan="1">RFC 9290, <xref target="media-type"/></td> target="media-type" format="default" sectionFormat="of" derivedContent="Section 6.3"/></td>
            </tr>
          </tbody>
        </table>
        <dl spacing="compact">
          <dt>Type indent="3" newline="false" spacing="normal" pn="section-6.3-3">
          <dt pn="section-6.3-3.1">Type name:</dt>
          <dd>
            <t>application</t>
          <dd pn="section-6.3-3.2">
            <t indent="0" pn="section-6.3-3.2.1">application</t>
          </dd>
          <dt>Subtype
          <dt pn="section-6.3-3.3">Subtype name:</dt>
          <dd>
            <t>concise-problem-details+cbor</t>
          <dd pn="section-6.3-3.4">
            <t indent="0" pn="section-6.3-3.4.1">concise-problem-details+cbor</t>
          </dd>
          <dt>Required
          <dt pn="section-6.3-3.5">Required parameters:</dt>
          <dd>
            <t>N/A</t>
          <dd pn="section-6.3-3.6">
            <t indent="0" pn="section-6.3-3.6.1">N/A</t>
          </dd>
          <dt>Optional
          <dt pn="section-6.3-3.7">Optional parameters:</dt>
          <dd>
            <t>N/A</t>
          <dd pn="section-6.3-3.8">
            <t indent="0" pn="section-6.3-3.8.1">N/A</t>
          </dd>
          <dt>Encoding
          <dt pn="section-6.3-3.9">Encoding considerations:</dt>
          <dd>
            <t>binary
          <dd pn="section-6.3-3.10">
            <t indent="0" pn="section-6.3-3.10.1">binary (CBOR data item)</t>
          </dd>
          <dt>Security
          <dt pn="section-6.3-3.11">Security considerations:</dt>
          <dd>
            <t><xref target="seccons"/>
          <dd pn="section-6.3-3.12">
            <t indent="0" pn="section-6.3-3.12.1"><xref target="seccons" format="default" sectionFormat="of" derivedContent="Section 5"/> of RFC XXXX</t> 9290</t>
          </dd>
          <dt>Interoperability
          <dt pn="section-6.3-3.13">Interoperability considerations:</dt>
          <dd>
            <t>none</t>
          <dd pn="section-6.3-3.14">
            <t indent="0" pn="section-6.3-3.14.1">none</t>
          </dd>
          <dt>Published
          <dt pn="section-6.3-3.15">Published specification:</dt>
          <dd>
            <t><xref target="media-type"/>
          <dd pn="section-6.3-3.16">
            <t indent="0" pn="section-6.3-3.16.1"><xref target="media-type" format="default" sectionFormat="of" derivedContent="Section 6.3"/> of RFC XXXX</t> 9290</t>
          </dd>
          <dt>Applications
          <dt pn="section-6.3-3.17">Applications that use this media type:</dt>
          <dd>
            <t>Clients
          <dd pn="section-6.3-3.18">
            <t indent="0" pn="section-6.3-3.18.1">Clients and servers in the Internet of Things</t>
          </dd>
          <dt>Fragment
          <dt pn="section-6.3-3.19">Fragment identifier considerations:</dt>
          <dd>
            <t>The
          <dd pn="section-6.3-3.20">
            <t indent="0" pn="section-6.3-3.20.1">The syntax and semantics of fragment identifiers is as specified for
"application/cbor".  (At publication of RFC XXXX, 9290, there is no
fragment identification syntax defined for "application/cbor".)</t>
          </dd>
          <dt>Person
          <dt pn="section-6.3-3.21">Additional information:</dt>
          <dd pn="section-6.3-3.22">
            <t indent="0" pn="section-6.3-3.22.1"><br/></t>
            <dl spacing="compact" indent="3" newline="false" pn="section-6.3-3.22.2">
              <dt pn="section-6.3-3.22.2.1">Deprecated alias names for this type:</dt>
              <dd pn="section-6.3-3.22.2.2">N/A</dd>
              <dt pn="section-6.3-3.22.2.3">Magic number(s):</dt>
              <dd pn="section-6.3-3.22.2.4">N/A</dd>
              <dt pn="section-6.3-3.22.2.5">File extension(s):</dt>
              <dd pn="section-6.3-3.22.2.6">N/A</dd>
              <dt pn="section-6.3-3.22.2.7">Macintosh file type code(s):</dt>
              <dd pn="section-6.3-3.22.2.8">N/A</dd>
            </dl>
          </dd>
          <dt pn="section-6.3-3.23">Person &amp; email address to contact for further information:</dt>
          <dd>
            <t>CoRE
          <dd pn="section-6.3-3.24">
            <t indent="0" pn="section-6.3-3.24.1">CoRE WG mailing list (core@ietf.org), (core@ietf.org)
or IETF Applications and Real-Time Area (art@ietf.org)</t>
          </dd>
          <dt>Intended
          <dt pn="section-6.3-3.25">Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          <dd pn="section-6.3-3.26">
            <t indent="0" pn="section-6.3-3.26.1">COMMON</t>
          </dd>
          <dt>Restrictions
          <dt pn="section-6.3-3.27">Restrictions on usage:</dt>
          <dd>
            <t>none</t>
          <dd pn="section-6.3-3.28">
            <t indent="0" pn="section-6.3-3.28.1">none</t>
          </dd>
          <dt>Author/Change
          <dt pn="section-6.3-3.29">Author/Change controller:</dt>
          <dd>
            <t>IETF</t>
          <dd pn="section-6.3-3.30">
            <t indent="0" pn="section-6.3-3.30.1">IETF</t>
          </dd>
          <dt>Provisional
          <dt pn="section-6.3-3.31">Provisional registration:</dt>
          <dd>
            <t>no</t>
          <dd pn="section-6.3-3.32">
            <t indent="0" pn="section-6.3-3.32.1">no</t>
          </dd>
        </dl>
      </section>
      <section anchor="content-format">
        <name>Content-Format</name>
        <t>IANA is requested to register anchor="content-format" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-content-format">Content-Format</name>
        <t indent="0" pn="section-6.4-1">IANA has registered a Content-Format number in the
<xref section="&quot;CoAP Content-Formats&quot;" relative="#content-formats" sectionFormat="bare" target="IANA.core-parameters"/>
sub-registry, target="IANA.core-parameters" format="default" derivedLink="https://www.iana.org/assignments/core-parameters#content-formats" derivedContent="IANA.core-parameters"/>
subregistry, within the "Constrained RESTful Environments (CoRE)
Parameters" Registry registry <xref target="IANA.core-parameters"/>, target="IANA.core-parameters" format="default" sectionFormat="of" derivedContent="IANA.core-parameters"/>, as follows:</t>
        <table align="left">
          <name>New Content-Format</name> align="left" pn="table-4">
          <name slugifiedName="name-content-format-registration">Content-Format Registration</name>
          <thead>
            <tr>
              <th align="left">Content-Type</th> align="left" colspan="1" rowspan="1">Media Type</th>
              <th align="left">Content Coding</th> align="left" colspan="1" rowspan="1">Encoding</th>
              <th align="left">ID</th> align="left" colspan="1" rowspan="1">ID</th>
              <th align="left">Reference</th> align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">application/concise-problem-details+cbor</td> align="left" colspan="1" rowspan="1">application/concise-problem-details+cbor</td>
              <td align="left">-</td> align="left" colspan="1" rowspan="1">-</td>
              <td align="left">TBD1</td> align="left" colspan="1" rowspan="1">257</td>
              <td align="left">RFC XXXX</td> align="left" colspan="1" rowspan="1">RFC 9290</td>
            </tr>
          </tbody>
        </table>
        <t>TBD1 is to be assigned from the space 256..999.</t>
        <t>In the registry as defined by <xref section="12.3" sectionFormat="of" target="RFC7252"/> at the time of
writing, the column "Content-Type" is called "Media type" and the
column "Content Coding" is called "Encoding". <cref anchor="remove">This paragraph to be removed by RFC editor.</cref></t>
      </section>
      <section anchor="iana-tag38">
        <name>CBOR anchor="iana-tag38" numbered="true" removeInRFC="false" toc="include" pn="section-6.5">
        <name slugifiedName="name-cbor-tag-38">CBOR Tag 38</name>
        <t>In
        <t indent="0" pn="section-6.5-1">In the registry "<xref section="CBOR Tags" relative="#cbor-tags" sectionFormat="bare" target="IANA.cbor-tags"/>" target="IANA.cbor-tags" format="default" derivedLink="https://www.iana.org/assignments/cbor-tags#cbor-tags" derivedContent="IANA.cbor-tags"/>" <xref target="IANA.cbor-tags"/>, target="IANA.cbor-tags" format="default" sectionFormat="of" derivedContent="IANA.cbor-tags"/>,
	IANA has registered CBOR Tag tag 38.

IANA is requested to replace has updated the reference for this registration with
<xref target="tag38"/>, CBOR tag 38 to point to RFC XXXX.</t> 9290, <xref target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative
    <displayreference target="I-D.ietf-httpapi-rfc7807bis" to="HTTPAPI"/>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="STD94" target="https://www.rfc-editor.org/info/rfc8949"> anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags" quoteTitle="true" derivedAnchor="IANA.cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/> (CBOR) Tags</title>
            <author>
              <organization abbrev="IANA" showOnFrontPage="true">Internet Assigned Numbers Authority</organization>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters" quoteTitle="true" derivedAnchor="IANA.core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization abbrev="IANA" showOnFrontPage="true">Internet Assigned Numbers Authority</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.media-types" target="https://www.iana.org/assignments/provisional-standard-media-types" quoteTitle="true" derivedAnchor="IANA.media-types">
          <front>
            <title>Provisional Standard Media Type Registry</title>
            <author>
              <organization abbrev="IANA" showOnFrontPage="true">Internet Assigned Numbers Authority</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="December" year="2020"/> month="March" year="1997"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include
              <t indent="0">In many standards track documents several words are used to signify the possibility of extremely small code size, fairly small message size, and extensibility without requirements in the need for version negotiation. specification.  These design goals make it different from earlier binary serializations such words are often capitalized.  This document defines these words as ASN.1 and MessagePack.</t>
              <t>This they should be interpreted in IETF documents.  This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of specifies an Internet Best Current Practices for the format.</t> Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/> name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8949"/> value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/> value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="STD66" target="https://www.rfc-editor.org/info/rfc3986"> anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4647" quoteTitle="true" derivedAnchor="RFC4647">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <title>Matching of Language Tags</title>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author> fullname="A. Phillips" initials="A." role="editor" surname="Phillips"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author> fullname="M. Davis" initials="M." role="editor" surname="Davis"/>
            <date month="January" year="2005"/> month="September" year="2006"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is
              <t indent="0">This document describes a compact sequence syntax, called a "language-range", for specifying items in a user's list of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax language preferences.  It also describes different mechanisms for comparing and matching these to language tags.  Two kinds of matching mechanisms, filtering and lookup, are defined.  Filtering produces a process for resolving URI references that might be (potentially empty) set of language tags, whereas lookup produces a single language tag.  Possible applications include language negotiation or content selection.  This document, in relative form, along combination with guidelines RFC 4646, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and security considerations requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="47"/>
          <seriesInfo name="RFC" value="4647"/>
          <seriesInfo name="DOI" value="10.17487/RFC4647"/>
        </reference>
        <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646" quoteTitle="true" derivedAnchor="RFC5646">
          <front>
            <title>Tags for Identifying Languages</title>
            <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips"/>
            <author fullname="M. Davis" initials="M." role="editor" surname="Davis"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the use structure, content, construction, and semantics of URIs on the Internet.  The URI syntax defines a grammar that language tags for use in cases where it is a superset of all valid URIs, allowing an implementation desirable to parse indicate the common components of a URI reference without knowing language used in an information object.  It also describes how to register values for use in language tags and the scheme-specific requirements creation of every possible identifier. user-defined extensions for private interchange.  This specification does not define a generative grammar document specifies an Internet Best Current Practices for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t> Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/> name="BCP" value="47"/>
          <seriesInfo name="RFC" value="3986"/> value="5646"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/> value="10.17487/RFC5646"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252"> target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author> surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author> surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author> surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The
              <t indent="0">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
              <t indent="0">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="RFC7807" target="https://www.rfc-editor.org/info/rfc7807"> target="https://www.rfc-editor.org/info/rfc7807" quoteTitle="true" derivedAnchor="RFC7807">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author> surname="Nottingham"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde">
              <organization/>
            </author> surname="Wilde"/>
            <date month="March" year="2016"/>
            <abstract>
              <t>This
              <t indent="0">This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7807"/>
          <seriesInfo name="DOI" value="10.17487/RFC7807"/>
        </reference>
        <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="19" month="September" year="2013"/>
          </front>
        </reference>
        <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5646"> anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Tags
            <title>Guidelines for Identifying Languages</title>
            <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips">
              <organization/>
            </author> Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Davis" Cotton" initials="M." role="editor" surname="Davis">
              <organization/>
            </author> surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="September" year="2009"/> month="June" year="2017"/>
            <abstract>
              <t>This document describes the structure, content, construction, and semantics
              <t indent="0">Many protocols make use of language tags for points of extensibility that use constants to identify various protocol parameters. To ensure that the values in cases where it is desirable these fields do not have conflicting uses and to indicate promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the language used Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in an information object.  It also describes a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to register existing values can be made, is needed. This document defines a framework for use in language tags and the creation documentation of user-defined extensions for private interchange.  This document  specifies an Internet Best Current Practices these guidelines by specification authors, in order to assure that the provided guidance for the Internet Community, and requests discussion IANA Considerations is clear and suggestions for improvements.</t> addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="47"/> value="26"/>
          <seriesInfo name="RFC" value="5646"/> value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC5646"/> value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4647"> anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Matching
            <title>Ambiguity of Language Tags</title>
            <author fullname="A. Phillips" initials="A." role="editor" surname="Phillips">
              <organization/>
            </author> Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="M. Davis" initials="M." role="editor" surname="Davis">
              <organization/>
            </author> fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="September" year="2006"/> month="May" year="2017"/>
            <abstract>
              <t>This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences.  It also describes different mechanisms for comparing and matching these to language tags.  Two kinds of matching mechanisms, filtering and lookup, are defined.  Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection.  This document,
              <t indent="0">RFC 2119 specifies common key words that may be used in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. protocol specifications.  This document specifies an Internet Best Current Practices for aims to reduce the Internet Community, and requests discussion and suggestions for improvements.</t> ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="47"/> value="14"/>
          <seriesInfo name="RFC" value="4647"/> value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC4647"/> value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610"> target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="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> surname="Birkholz"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author> surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author> surname="Bormann"/>
            <date month="June" year="2019"/>
            <abstract>
              <t>This
              <t indent="0">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="RFC9165" target="https://www.rfc-editor.org/info/rfc9165"> target="https://www.rfc-editor.org/info/rfc9165" quoteTitle="true" derivedAnchor="RFC9165">
          <front>
            <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author> surname="Bormann"/>
            <date month="December" year="2021"/>
            <abstract>
              <t>The
              <t indent="0">The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</t>
              <t>The
              <t indent="0">The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9165"/>
          <seriesInfo name="DOI" value="10.17487/RFC9165"/>
        </reference>
        <referencegroup anchor="STD66" target="https://www.rfc-editor.org/info/std66" derivedAnchor="STD66">
          <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126"> anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true">
            <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
              <title>Uniform Resource Identifier (URI): Generic Syntax</title>
              <author fullname="T. Narten" Berners-Lee" initials="T." surname="Narten">
              <organization/>
            </author> surname="Berners-Lee"/>
              <author fullname="R. Fielding" initials="R." surname="Fielding"/>
              <author fullname="L. Masinter" initials="L." surname="Masinter"/>
              <date month="June" year="2017"/> month="January" year="2005"/>
              <abstract>
              <t>Many protocols make use of points
                <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of extensibility that use constants to identify various protocol parameters.  To ensure characters that identifies an abstract or physical resource.  This specification defines the values in these fields do not have conflicting uses generic URI syntax and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, process for resolving URI references that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should might be assigned, as well as when in relative form, along with guidelines and how modifications to existing values can be made, is needed.  This document defines a framework security considerations for the documentation use of these guidelines by specification authors, in order to assure that the provided guidance for URIs on the IANA Considerations Internet.  The URI syntax defines a grammar that is clear and addresses a superset of all valid URIs, allowing an implementation to parse the various issues that are likely in common components of a URI reference without knowing the operation scheme-specific requirements of every possible identifier.  This specification does not define a registry.</t>
              <t>This generative grammar for URIs; that task is performed by the third edition individual specifications of this document; it obsoletes RFC 5226.</t> each URI scheme. [STANDARDS-TRACK]</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="26"/> name="STD" value="66"/>
            <seriesInfo name="RFC" value="8126"/> value="3986"/>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/> value="10.17487/RFC3986"/>
          </reference>
        </referencegroup>
        <referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94" derivedAnchor="STD94">
          <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true">
            <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
              <title>Concise Binary Object Representation (CBOR)</title>
              <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author> fullname="C. Bormann" initials="C." surname="Bormann"/>
              <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
              <date month="March" year="1997"/> month="December" year="2020"/>
              <abstract>
              <t>In many standards track documents several words are used to signify
                <t indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the requirements in possibility of extremely small code size, fairly small message size, and extensibility without the specification. need for version negotiation. These words are often capitalized. This document defines these words design goals make it different from earlier binary serializations such as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, ASN.1 and requests discussion MessagePack.</t>
                <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity errata fixes while keeping full compatibility with the interchange format of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage 7049. It does not create a new version of the key words have the  defined special meanings.</t> format.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="14"/> name="STD" value="94"/>
            <seriesInfo name="RFC" value="8174"/> value="8949"/>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="8" month="June" year="2012"/>
          </front>
        </reference>
        <reference anchor="IANA.media-types" target="https://www.iana.org/assignments/provisional-standard-media-types">
          <front>
            <title>Provisional Standard Media Type Registry</title>
            <author>
              <organization abbrev="IANA">Internet Assigned Numbers Authority</organization>
            </author>
            <date day="20" month="July" year="2012"/>
          </front> value="10.17487/RFC8949"/>
          </reference>
        </referencegroup>
      </references>
      <references>
        <name>Informative
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <date month="October" year="2006"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="I-D.ietf-httpapi-rfc7807bis" target="https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-03.txt"> quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-rfc7807bis-04" derivedAnchor="HTTPAPI">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
         </author>
            <author initials="E." surname="Wilde" fullname="Erik Wilde">
         </author>
            <author initials="S." surname="Dalal" fullname="Sanjay Dalal">
         </author>
            <date day="25" month="May" month="September" day="5" year="2022"/>
            <abstract>
              <t>
              <t indent="0">   This document defines a "problem detail" to carry machine-readable
   details of errors in HTTP response content and/or fields to avoid the
   need to define new error response formats for HTTP APIs.

   This document obsoletes RF7807.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-httpapi/rfc7807bis.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis-03"/> value="draft-ietf-httpapi-rfc7807bis-04"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-httpapi-rfc7807bis-04.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RDF" target="http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/"> target="http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/" quoteTitle="true" derivedAnchor="RDF">
          <front>
            <title>RDF 1.1 Concepts and Abstract Syntax</title>
            <author initials="R." surname="Cyganiak" fullname="Richard Cyganiak">
              <organization/>
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wood" fullname="David Wood">
              <organization/>
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Lanthaler" fullname="Markus Lanthaler">
              <organization/>
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="February" day="25"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC6082" target="https://www.rfc-editor.org/info/rfc6082"> target="https://www.rfc-editor.org/info/rfc6082" quoteTitle="true" derivedAnchor="RFC6082">
          <front>
            <title>Deprecating Unicode Language Tag Characters: RFC 2482 is Historic</title>
            <author fullname="K. Whistler" initials="K." surname="Whistler">
              <organization/>
            </author> surname="Whistler"/>
            <author fullname="G. Adams" initials="G." surname="Adams">
              <organization/>
            </author> surname="Adams"/>
            <author fullname="M. Duerst" initials="M." surname="Duerst">
              <organization/>
            </author> surname="Duerst"/>
            <author fullname="R. Presuhn" initials="R." role="editor" surname="Presuhn">
              <organization/>
            </author> surname="Presuhn"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author> surname="Klensin"/>
            <date month="November" year="2010"/>
            <abstract>
              <t>RFC
              <t indent="0">RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML.  The Unicode Consortium has deprecated that facility and strongly recommends against its use.  RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6082"/>
          <seriesInfo name="DOI" value="10.17487/RFC6082"/>
        </reference>
        <reference anchor="Unicode-14.0.0" target="https://www.unicode.org/versions/Unicode14.0.0/"> target="https://www.unicode.org/versions/Unicode14.0.0/" quoteTitle="true" derivedAnchor="Unicode-14.0.0">
          <front>
            <title>The Unicode Standard, Version 14.0.0</title>
            <author>
              <organization>The
              <organization showOnFrontPage="true">The Unicode Consortium</organization>
            </author>
            <date year="2021" month="September"/>
          </front>
          <seriesInfo name="ISBN" value="978-1-936213-29-0"/>
          <annotation>Note that while this document references a version that was recent at the time of writing, the statements made based on this version are expected to remain valid for future versions.</annotation>
          <refcontent>Mountain View: The Unicode Consortium</refcontent>
        </reference>
        <reference anchor="Unicode-14.0.0-bidi" target="https://www.unicode.org/reports/tr9/#Markup_And_Formatting"> target="https://www.unicode.org/reports/tr9/#Markup_And_Formatting" quoteTitle="true" derivedAnchor="Unicode-14.0.0-bidi">
          <front>
            <title>Unicode®
            <title>Unicode Standard Annex #9 --- Unicode Bidirectional Algorithm</title>
            <author>
              <organization>The
              <organization showOnFrontPage="true">The Unicode Consortium</organization>
            </author>
            <date year="2021" month="August" day="27"/>
          </front>
          <annotation>Note that while this document references a version that was recent at the time of writing, the statements made based on this version are expected to remain valid for future versions.</annotation>
        </reference>
      </references>
    </references>
    <section anchor="tag38">
      <name>Language-Tagged anchor="tag38" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-language-tagged-strings">Language-Tagged Strings</name>
      <t>This
      <t indent="0" pn="section-appendix.a-1">This appendix serves as the archival documentation for CBOR Tag tag 38, a
tag for serializing language-tagged text strings in CBOR.
The text of this appendix is adapted from the specification text
supplied for its initial registration.
It has been extended to allow supplementing the language tag by a
direction indication.</t>
      <t>As
      <t indent="0" pn="section-appendix.a-2">As with any IANA-registered item, a specification that further updates this
registration needs to update the reference column of the IANA registry (see
<xref target="iana-tag38"/>). target="iana-tag38" format="default" sectionFormat="of" derivedContent="Section 6.5"/>).
Future specifications may update this appendix, other parts of this document,
or both.
(When updating this appendix, keep in mind that applications beyond
concise problem details
Concise Problem Details data items may adopt the tag defined here.)
Users of this tag are advised to consult the registry to obtain the
most recent update for this appendix.</t>
      <section anchor="introduction-1">
        <name>Introduction</name>
        <t>In anchor="introduction-1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-introduction-2">Introduction</name>
        <t indent="0" pn="section-appendix.a.1-1">In some cases cases, it is useful to specify the natural language of a text
string.  This specification defines a tag that does just that.  One
technology that supports language-tagged strings is the Resource
Description Framework (RDF) <xref target="RDF"/>.</t> target="RDF" format="default" sectionFormat="of" derivedContent="RDF"/>.</t>
      </section>
      <section anchor="detailed-semantics">
        <name>Detailed anchor="detailed-semantics" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-detailed-semantics">Detailed Semantics</name>
        <t>A
        <t indent="0" pn="section-appendix.a.2-1">A language-tagged text string in CBOR has the tag 38 and consists of an array
with a length of 2 or 3.</t>
        <t>The
        <t indent="0" pn="section-appendix.a.2-2">The first element is a well-formed language tag under Best Current
Practice described in BCP 47 (<xref target="RFC5646"/> target="RFC5646" format="default" sectionFormat="of" derivedContent="RFC5646"/> and <xref target="RFC4647"/>), target="RFC4647" format="default" sectionFormat="of" derivedContent="RFC4647"/>), represented as a UTF-8 text
string (major type 3).</t>
        <t>The
        <t indent="0" pn="section-appendix.a.2-3">The second element is an arbitrary UTF-8 text string (major type
3). Both the language tag and the arbitrary string can optionally be
annotated with CBOR tags; this is not shown in the CDDL below.</t>
        <t>The
        <t indent="0" pn="section-appendix.a.2-4">The optional third element, if present, represents a ternary value that
indicates a direction, as follows:</t>
        <ul spacing="normal">
          <li> spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-5">
          <li pn="section-appendix.a.2-5.1">
            <tt>false</tt>: left-to-right direction ("ltr").
The text is expected to be displayed with left-to-right base
direction if standalone, standalone and isolated with left-to-right direction
(as if enclosed in LRI ... PDI or equivalent, see <xref target="Unicode-14.0.0-bidi"/>) target="Unicode-14.0.0-bidi" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0-bidi"/>) in the
context of a longer string or text.</li>
          <li>
          <li pn="section-appendix.a.2-5.2">
            <tt>true</tt>: right-to-left direction ("rtl").
The text is expected to be displayed with right-to-left base
direction if standalone, standalone and isolated with right-to-left direction
(as if enclosed in RLI ... PDI or equivalent, see <xref target="Unicode-14.0.0-bidi"/>) target="Unicode-14.0.0-bidi" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0-bidi"/>) in the context
of a longer string or text.</li>
          <li>
            <tt>null</tt>
          <li pn="section-appendix.a.2-5.3">
            <tt>null:</tt> indicates that no indication is made about the direction
("auto"), enabling an internationalization library to make an auto-detection
decision such as treating the string as if enclosed in FSI ... PDI
or equivalent, see <xref target="Unicode-14.0.0-bidi"/>.</li> target="Unicode-14.0.0-bidi" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0-bidi"/>.</li>
        </ul>
        <t>If
        <t indent="0" pn="section-appendix.a.2-6">If the third element is absent, directionality context may be applying applied
(e.g., base directionality base-directionality information for an entire CBOR message or
part thereof).  If there is no directionality context applying, applied, the
default interpretation is the same as for <tt>null</tt> ("auto").</t>
        <t>In
        <t indent="0" pn="section-appendix.a.2-7">In CDDL:</t>
        <sourcecode type="cddl"><![CDATA[ type="cddl" markers="false" pn="section-appendix.a.2-8">
tag38 = #6.38([tag38-ltag, text, ?tag38-direction])
tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
tag38-direction = &(ltr: &amp;(ltr: false, rtl: true, auto: null)
]]></sourcecode>
        <!-- RUBY_THREAD_VM_STACK_SIZE=5000000 cddl ... -->

<t>NOTE:
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-9">NOTE: Language tags of any combination of case are allowed. But
<xref section="2.1.1" sectionFormat="of" target="RFC5646"/>, target="RFC5646" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5646#section-2.1.1" derivedContent="RFC5646"/>, part of Best Current Practice BCP 47,
recommends a case combination for language tags that encoders that
support tag 38 may wish to follow when generating language tags.</t>
        <t>Data
        <t indent="0" pn="section-appendix.a.2-10">Data items with tag 38 that do not meet the criteria above are not valid
(see Section <xref section="5.3.2" sectionFormat="bare" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-5.3.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" target="STD94"/>).</t>
        <t>NOTE: derivedContent="STD94"/>).</t>
        <t indent="0" pn="section-appendix.a.2-11">NOTE: The Unicode Standard <xref target="Unicode-14.0.0"/> target="Unicode-14.0.0" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0"/> includes a set of characters
designed for tagging text (including language tagging), tagging) in the range
U+E0000 to U+E007F. Although many applications, including RDF,
do not disallow these characters in text strings, the Unicode Consortium
has deprecated these characters and recommends annotating language via a
higher-level protocol instead. See the section "Deprecated Tag
Characters" in Section 23.9 of <xref target="Unicode-14.0.0"/>, target="Unicode-14.0.0" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0"/> as well as <xref target="RFC6082"/>.</t> target="RFC6082" format="default" sectionFormat="of" derivedContent="RFC6082"/>.</t>
        <t indent="0" pn="section-appendix.a.2-12">NOTE: while this document references a version of Unicode that was
              recent at the time of writing, the statements made based
              on this version are expected to remain valid for future
              versions.</t>
      </section>
      <section anchor="examples">
        <name>Examples</name>
        <t>Examples anchor="examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-examples">Examples</name>
        <t indent="0" pn="section-appendix.a.3-1">Examples in this section are given in CBOR diagnostic notation first and then
as a pretty-printed hexadecimal representation of the encoded item.</t>
        <t>The
        <t indent="0" pn="section-appendix.a.3-2">The following example shows how the English-language string "Hello" is
represented.</t>
        <sourcecode type="cbor-diag"><![CDATA[ type="cbor-diag" markers="false" pn="section-appendix.a.3-3">
38(["en", "Hello"])
]]></sourcecode>
</sourcecode>
        <sourcecode type="cbor-pretty"><![CDATA[ type="cbor-pretty" markers="false" pn="section-appendix.a.3-4">
D8 26               # tag(38)
   82               # array(2)
      62            # text(2)
         656E       # "en"
      65            # text(5)
         48656C6C6F # "Hello"
]]></sourcecode>
        <t>The
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-5">The following example shows how the French-language string "Bonjour" is
represented.</t>
        <sourcecode type="cbor-diag"><![CDATA[ type="cbor-diag" markers="false" pn="section-appendix.a.3-6">
38(["fr", "Bonjour"])
]]></sourcecode>
</sourcecode>
        <sourcecode type="cbor-pretty"><![CDATA[ type="cbor-pretty" markers="false" pn="section-appendix.a.3-7">
D8 26                   # tag(38)
   82                   # array(2)
      62                # text(2)
         6672           # "fr"
      67                # text(7)
         426F6E6A6F7572 # "Bonjour"
]]></sourcecode>
        <t>The
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-8">The following example uses right-to-left (RTL) script, which in the context of this specification may be rendered differently by different document presentation environments.  The descriptive text may be more reliable to follow than the necessarily device- and application-specific rendering.
The example shows how the Hebrew-language string
<u>שלום</u> is represented. string</t>
        <artwork align="left" pn="section-appendix.a.3-9">
שלום
</artwork>
        <t indent="0" pn="section-appendix.a.3-10">is represented, where in direction of reading, the sequence of characters is:
<u format="lit-name-num" pn="u-1">ש</u>,
<u format="lit-name-num" pn="u-2">ל</u>,
<u format="lit-name-num" pn="u-3">ו</u>,
<u format="lit-name-num" pn="u-4">ם</u>.
Note the <tt>rtl</tt> direction expressed by setting the third element in the array to "true".</t>
        <sourcecode type="cbor-diag"><![CDATA[ type="cbor-diag" markers="false" pn="section-appendix.a.3-11">
38(["he", "שלום", true])
]]></sourcecode>
</sourcecode>
        <sourcecode type="cbor-pretty"><![CDATA[ type="cbor-pretty" markers="false" pn="section-appendix.a.3-12">
D8 26                     # tag(38)
   83                     # array(3)
      62                  # text(2)
         6865             # "he"
      68                  # text(8)
         D7A9D79CD795D79D # "שלום"
      F5                  # primitive(21)
]]></sourcecode>
</sourcecode>
      </section>
    </section>
    <section anchor="comp7807">
      <name>Interworking anchor="comp7807" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-interworking-with-rfc-7807">Interworking with RFC 7807</name>
      <t>On
      <t indent="0" pn="section-appendix.b-1">On certain occasions, it will be necessary to carry ("tunnel")
<xref target="RFC7807"/> target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/> problem details in a Concise Problem Details data item.</t>
      <t>This
      <t indent="0" pn="section-appendix.b-2">This appendix defines a Custom Problem Details Detail entry for that purpose.
This is assigned Custom Problem Detail key 7807 in <xref target="iana-cpdk"/>. target="iana-cpdk" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.
Its structure is:</t>
      <sourcecode type="cddl"><![CDATA[ type="cddl" markers="false" pn="section-appendix.b-3">
tunnel-7807 = {
  ? &(type: &amp;(type: 0) => =&gt; ~uri
  ? &(status: &amp;(status: 1) => =&gt; 0..999
  * text => =&gt; any
}
]]></sourcecode>
      <t>To
</sourcecode>
      <t indent="0" pn="section-appendix.b-4">To carry an <xref target="RFC7807"/> target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/> problem details JSON object in a Concise Problem
Details data item, first convert the JSON object to CBOR as per Section <xref section="6.2" sectionFormat="bare" target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFormat="of" target="STD94"/>. derivedContent="STD94"/>.  Create an empty Concise Problem Details data item.</t>
      <t>Move
      <t indent="0" pn="section-appendix.b-5">Move the values for "title", "detail", and "instance", if present,
from the <xref target="RFC7807"/> target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/> problem details to the equivalent Standard Problem
Detail entries.
Create a Custom Problem Details Detail entry with key 7807.
Move the values for "type" and "status", if present, to the equivalent
keys 0 and 1 of the Custom Problem Details Detail entry.
Move all remaining key/value pairs (additional members as per <xref section="3.2" sectionFormat="of" target="RFC7807"/>) target="RFC7807" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7807#section-3.2" derivedContent="RFC7807"/>) in the converted <xref target="RFC7807"/> target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7807"/> problem
details object to the Custom Problem Details Detail map unchanged.</t>
      <t>The
      <t indent="0" pn="section-appendix.b-6">The inverse direction, carrying Concise Problem Details in a Problem
Details an RFC 7807 problem
details JSON object requires the additional support provided by
<xref target="I-D.ietf-httpapi-rfc7807bis"/>, target="I-D.ietf-httpapi-rfc7807bis" format="default" sectionFormat="of" derivedContent="HTTPAPI"/>, which is planned to create the HTTP Problem Types
Registry.  An HTTP Problem Type can then be registered that extracts
top-level items from the Concise Problem Details data item in a similar way
to the conversion described above, above and which that carries the rest of the
Concise Problem Details data item in an additional member via base64url
encoding without padding (<xref section="5" sectionFormat="of" target="RFC4648"/>). target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/>).  Details can be defined
in a separate document when the work on <xref target="I-D.ietf-httpapi-rfc7807bis"/> target="I-D.ietf-httpapi-rfc7807bis" format="default" sectionFormat="of" derivedContent="HTTPAPI"/> is completed.</t>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t><contact anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.c-1">The authors would like to thank <contact fullname="Mark Nottingham"/> and <contact fullname="Erik Wilde"/>, the authors of RFC 7807. 7807;  <contact fullname="Klaus Hartke"/> and <contact fullname="Jaime Jiménez"/>, co-authors the coauthors of an earlier generation draft version of this
specification.
specification;  <contact fullname="Christian Amsüss"/>, <contact fullname="Marco Tiloca"/>, <contact fullname="Ari Keränen"/> Keränen"/>,
and <contact fullname="Michael Richardson"/> for review and comments on this document.
<contact fullname="Francesca Palombini"/> for her review (and support) as responsible AD,
and <contact fullname="Joel Jaeggli"/> for his OPSDIR review, both of which brought
significant additional considerations to this document.</t>
      <t>For
      <t indent="0" pn="section-appendix.c-2">For <xref target="tag38"/>, target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>, <contact fullname="John Cowan"/> and <contact fullname="Doug Ewell"/> are also to be acknowledged.
The content of an earlier draft version of this appendix was also discussed
in the "apps-discuss at ietf.org" "apps-discuss@ietf.org" and "ltru at ietf.org" "ltru@ietf.org" mailing
lists.
More recently, the authors initiated a discussion about the handling
of writing direction information in conjunction with language tags.
That led to discussions within the W3C Internationalization Core
Working Group.
The authors would like to acknowledge that cross-organization
cooperation and particular contributions from <contact fullname="John Klensin"/> and
<contact fullname="Addison Phillips"/>, Phillips"/> and specific text proposals by <contact fullname="Martin Dürst"/>.</t>
      <!--  LocalWords:  dereferencing dereferenced dereferenceable
 -->
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name> removeInRFC="false" pn="section-appendix.d">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="P." surname="Occil" fullname="Peter Occil">
        <organization/>
        <organization showOnFrontPage="true"/>
        <address>
          <email>poccil14 at gmail dot com</email>
          <email>poccil14@gmail.com</email>
          <uri>http://peteroupc.github.io/CBOR/</uri>
        </address>
      </contact>
      <t>Peter
      <t indent="0" pn="section-appendix.d-1">Peter defined CBOR tag 38, basis of <xref target="tag38"/>.</t> target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      <contact initials="C." surname="Amsüss" fullname="Christian Amsüss">
        <organization/>
        <organization showOnFrontPage="true"/>
        <address>
          <email>christian@amsuess.com</email>
        </address>
      </contact>
      <t>Christian
      <t indent="0" pn="section-appendix.d-2">Christian contributed what became <xref target="uco"/>.</t> target="uco" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Fossati" fullname="Thomas Fossati">
        <organization showOnFrontPage="true">Arm Limited</organization>
        <address>
          <email>thomas.fossati@arm.com</email>
        </address>
      </author>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+193XIjx5XmfT5FGh1hgRIKJMGfJtFSj9kkW6Kt/lmSstZW
aMQCUABLXaiCqwpkQxQd+xC7d7sRvpibudkn8JX1EL7fJ9nznZOZlVUAyJbt
mdiYHTqsJquyMk+ePHn+T2YQBOqmr3eUKuMyifr6OEuHcRHpt3k2SKKpPonK
ME4K/TLL6d3RW3309qxQ4WCQRzdofX7abKpG2TANp9TXKA/HZRBH5TgYZnkU
zKRhMJKGQRKWUVGqIf0zyfJFXxflSA2ztIjSYl70dZnPI1XMB9O4KOIsLRcz
6vTs9PKlUvEs5/dF2dvaOtzqqTCPwr4+Or9Ut1n+bpJn85kB72v6O04n+nM8
U++iBTUY9fU3mE0H0+k0Z9BR2v0cv3hzri/DSUd/GaaTeTiJ5K8X8Sj+Vqmi
DNPRd2GSpQTaIirULKauy2zY0UWWl3k0Lui3xRS/UPNwXl5neV/pQGvB0eV1
Ng2B3qIIy5gHzvJJmMY/0J9Z2tetMJ+2+Hk0JeBo1vxFdyxf/Iped4fZ1Ovy
OMyLMkr1iyyfhmlq++zrr9L4JsqLuPzpX0r9Io+m1Ojy92fcoCBYo7Kv32ZF
OQ6H13pnZ2t3d4vfDeOSFkc+kAfZiMY5CXoHO3uH5sk8LbGEn0cYdMEPZ9eM
lk92D4Pd3nbQ2z4I9ncOe9v+bIbhIPtV+UPcJQix9mUeD+ZlHUdvozLK9Zvh
ME78T2cZnmzv6rDUEzzSo6zUjAv6mee0EtdlOetvbs7QAa3+sDuJy+v5oBtn
m1jYTQO7GZXxLYONonGcRiNZ/jKc6J2Djh6ERVzobKzv7ujRzsH9fddH+3Ue
F2UcpvpoWvz056KoTdO+/FU4LeZRUXQtnPXRq07cc4Li9pqmOIiGNA6NPR9m
GFndROk8IjxpR+0prWLIcJ+fXlyO54k+TW/iPEtp4UrAY4ChzfgrbEtGOn3P
SJHnwe1kc9VmVSoFOZVEQRjy4vLkcLfPEwjow0GW8++f9fX5y+ODw91DabO/
79rQenhNdg4P9ulP+u1pb6+HocOZ+ftg66ksnAWBnp8dvT7qYpSAEA/OQP+V
5nv7u/t9PRjOgt2nwY48293ffeqe7cqzg/3tLRpmNErk78Pt/T35e5bMTV8H
2z3qi5AfggmpOB1XU36i9dc7x93z0+MgH4GfpcNoVhYBsZ/drR76psdu+IM+
iCUC5MFJlzkgZhTO4iAfDzHFQUzTML/gs5OXff1E9yy2pDNNE80n2JaGkG9v
b7u3O1i2zcvzzd7W9u6mgWh724dpm2Dq7Ql5O57DP4Gh1vN4eB3mROALMJvw
XeP1SXgTj4h1ZqPGi1dh/m5egBmW12ESybIb2UGT0NvdbZYhAEQTb9RHAxDl
sNQXi7QM33P7fNgHNvV5RLuAaHPEvI5f0a/UE2YQbPWC3p6gdH/roIcZEAcD
7wm2d7tb3a2KtuTxEsYKgzLznvHGHJCWd9P0JV1t+vO4vI7sSPoCDJ4Q1dG/
lQ+1fLCE2kB4rP8tNiQJgXg+rU2NWOGWcM0iyuOoAJ3Z5Tm7ePG6rw+fHgTb
weHOfm97J+gdBjIayRAwBdrKdsSPXoHt0o7Xv42j23WDfySwpsRenpthXmdl
RIKEuMrtdZzgV2JsJLfnYBQYKMojWkNaQW3wZVqTqMqjITUyHdGzkgYtY+JM
xBhv87gkWdvhhyQby4g5D/Edggg7YqS5q7gw39veSXzr6P0sGoLdlRkNMsW0
bsKEyJC2oR7Pyzm1savXXSKGYEAS2VEE/vggcsijGWGp2Czzw80nTNyz745I
pL/krY/J+JRh8WeG/sv/dvShj9I0eq+fHOogCNwiQEsgfIG6w0QfJaTmEK+d
/p3EcxD0nv6HXFMF3IWGYSh1WZuBiGSAPzQ6assICC0yqqVDvL0NFxhtGOb5
Qk1JlaGvAtIORyG1NU1Zikd5nuWFJpBClpcEYDGD9onPw5uMoKQpqzQS8GV8
nUa38mXVXMREwXPijqAj4y9WZq1IjjxR3FVYavlOxYChmBGhjPRgQWrGvKQH
tM9HMvAg0lOSyG7atGqprIbRW5VV0gHAF5eXoqQ7HYYmSCyUhY1B8TQmuRcp
EmpnpGRkozlTqFJ1LGCt54DNiEFa0mJOmiFhmS0B21CBXgvdvru7EFLXe91D
IDiAVL+/39A0wyKbRqCoQqekpBXz8TgexlhWLFWW3kQLQlA2n1zXxiPlcF4q
0oYE44KM6yiZkW7T1ZoJpCAKi6k3+aKikiKezmjBIYOi94TNIiZcqXFOYgwm
grekrOTd3QVQMO7vsdVCHROZF2hTzONS9tJsns+yIuqqsxIzojnHk9QtUR7N
C17AigQ62ImEsCFNIB7RZOPxQo+g36VE3q3iOpxFRQuYosUkhHsD20mhc3oZ
5xpkyHQzL9hq0cMk5n2I3ml8QRs241gPsvKaCeQ6nlwHSXQTJQaDwyQkxbQ9
L2ARoYVbbSziBmMLj4GXPJgY0vU2DV5avczr5iYjRX6ehPnCkd018ZuNrmzi
GbHSKE/RASQ+GLAsF2g/IQWMNkkppHp3N44nTe2T9d0//vGPOgyLm4nqBuan
q91P9Uz9qIVA9Y/V6+oZvT5m1NVfX0Q5MSJ6/RE6+YT+/1H1+iPzKBBZ6n/p
erBvzqM/kIJfLr3JgubP8x/X96bbY5o4sccN0+bTpc+z6utTXtxzu5b1fm9J
5NB+YCp3bxytkfZ/g1Wsvmma/g9AiTVRd6S5rlgz4v8lNlpA/H6SftaChIly
NmVZmn7WagzU16fvQ96zDDGWq3WvhFO6XTsjgkVHI5BOAuGeLHz26fNF/Shf
vLszFgcI7O6OaHMmf2GbDudFAU4ymyWGXAva0ETVzJ3zW+NXYGC9jgBYTjQA
gIhqnzzRl2QTx2mWZJMFb7BzeSti1LoVZKKl13ScZ1NmS8xFOxWH6nAv+JPY
OA3IEEbFM8xoRliPh9iJvOBqFIeTlGx6YiXEeN2mq+HAsu0DYdrCBWUI++pz
xa94vK46J2lKQpslfJgUWU3MEy8ah9M4iQkExk25Zl6+jccb/CytKy1W5chJ
PkFRIBCEbB1/lBkcn5x86aHD/Aa7jrsFXt+RfIHfp9CtV19dXLY68q9+/YZ/
Pz/9L1+dnZ+e4PeLL46+/NL9okyLiy/efPXlSfVb9eXxm1evTl+fyMf0VNce
qdaro9+1ZMVab95enr15ffRlC1DX9TOgUpDHxEVkDnSGhSIxM8zjgcz0xfHb
v/xpe5em+Auit9729iHP9xdsvD7dpT+IQFMZLUtpZ8ifhMaFIiqJaEmg7iQJ
SY1ZXNLadSDOi+vsNmWGTej6+Btg5tu+/pQs6O3d5+YBJlx7aHFWe8g4W36y
9LEgccWjFcM4bNaeNzBdh/fod7W/Ld69h1B+XoQFbYsms7h7Aj/PkDjP0Vpv
aMU948Ky1uqZo/pxliTZLWyIiojb+TyBFhRCVpOKlZeOiVyxV+mKaaG2QY23
aaMvQpC9GE1u+xnt7zSIprNy8ekdMdl/0r9sG6sl2N7Qnz3XWVKSImReyWf0
rrf8jtgpWTVDfLnDb/8ozhu8s/pCID7AYJcbzIlodbeIf4j0tmkIyyBgJ1yw
1+yE3yXE+OjlPr/kGQYJ/eM3yUtA+NRr4cwpBZelmF4NwRNEcJxFsEaIg5fZ
dN37++fGf7u+D8Jqm/r5WKeYIEEB1+aGUg927D5qAy2bmDfP4E5/gu9NN/oe
HVVr9uo5vnu1obvYvO1mY2ora0St+J9NwYhyIhhUYSXrhc8z1xHxCQj2jAgW
UrZtZK9YRgkp3qKRPboDWAFVYPrZnACHTz8X9hZ5jDzqTrodo9tFMlJgkAjS
B6EQr97Ankvn0wF1QWDUzTtt0CtSwdnddcCUa4RNRFzU7qM2m1DeA7tvjPqc
RxNSzIkDjjqqiOBmJUMvKGajd7TviCs667qj52kSv4t8kd/5EDRdhzdkTLKs
JH2CjApnviKw0SKzgrYdCVaZnw2K6HaWd4iXQ0GfJ8QxQrIQPyf9MkzKjYZC
bleC1oGkc5llI5G1LEVhbDTbV3o9nAOjrv6a5hgm7+iBCiv4+NsWa1EkKfKS
0HHXvylm4TC6F60FVKfbELLEa/qqr4+kZUdfz6dhWpnfxXw6hZHQAIRHgE/n
RbTIjAmyCuIO4RIsFzakbyJLt2A/JNuoG/7emlC+QUnKbpRWDLqBCECAQJdl
gEYBMTBPyZjCsMNkPjKeFqKdcMixD6J1sW2pC6y0tWantHQLRl2oychJi1AU
KgZ6OCSjTgx+zIi3jJCxXml2o4EdT7YJITi71VO8l5EELGnDoBSiDbhmt0xG
g4gNStZQL92wZgl7ZgkbawfCDVMDUc0+RVRkOJzn7GBqLJkZwKLUDLFjhvjq
/KxyTQnwxlIGI60t4wMjaGJjehoSWeX8D5C5iCOa53ieU8u8hs2Y1MjIDWox
UBNsBspdhhJvaw4PLU2cdlywwwNY3u51t7u9mu9jEpElzazUGCdZHk9ill9i
cYI2PgiFVqIa4PYccHjBmKy5YLYZDGasG4JZ2pJm7dlVwS65Iktu4DjPiecj
0lFfkUJHRGWjkSgiDOUaTqd0xet8eCHlDcD7DuDE2DyI5uh2JfsNnMaeMb4P
a/LJ4mWIi8zTcJTl7HuBKCTlinSoQrex7sYnwSG7jXVQUx9LHLqjhe+70F41
CdJDzByeujkYt2ilkdiJuAcrZ0MjN+bz82ej9OPyZnk2L+AUajGrbok5Yt2m
EIFEETqKea/gLweSBEAruFT7Cn9dbWhmaf5KTuoz0G2jz248q8PCnlHhdSSK
Y4uGkgkDfqKucrF2zBywGmzrCtv+jsYWqmNRWSyGxlz3nKnZoBS3FgtHDqm8
L5+BLfB6mQfs9y3MJwVx9BFmTCPdktaBmKzxqjywEEoWouU2gsG7pamWVT54
OwofCEm6no2JgwnTb1ttgWw5BwQcm3i2YWGts7dChTcEA3h2p0lc7Guu7Eue
RG03tqKUoVTL9N0ak71ItNNOynzDbA9LT2bJYQ2NbuICigumaoQlYx6ilx3i
pBLm7KCFhnCNZjJ1X+mpKQZOzxEfJjEmSLcod7zbUfI0EqEYj+0uI91pDrFN
AIxJGy0Qq4AD2TouxYtKcOWYZl3XILaN/QAYrZfMeJKJTwr3DgoSV2SjD+aT
CSOgWoiuOnaTrWxbOGjYh78ENWPB+/6ZMoNBwLRlBxXRMIBeSttEcgMKMHfQ
OKu38FWzqAZSSZcvFGMMdgopkLfhgulZ6F/oqwZvFUFi8KzIbjWkNCQsa8wi
MZ4Jh51GpNwokeAkjEm3l0YsYEaVfDFMPY98NvhR4YQYHBJqRujwZFklyeyC
16T16nWHRIULxBLkM8AloYaC2c8Kme5txEjaprEvkC35dtXnItYRQGLvyNws
aoEcjXqn7DIMC2sUkQI4DxMeXdmGzzzux/ot62YchyoKmHGMV1YlSBNiwIts
XN6G5pWy2qfV/a0fv+klkNWm7RonCa0PNNXCEn+y8EnWCoVySTcy5MrxE/Hr
RZKhAvEm2g3NbwVijQI0sahD6LEDtAxDOFqNb7VUpLQSbKSnD2nnQaq0xXwc
gKkI/5pGo5jtiJw+Hl5HG6Llwt1F8BUFHKqDbAS5O0N4kagRvC4jTZux5zNM
0zscY6mObtgrm2QTFnA0k0UZDwsFfg4S3TBLv7QMt8Co4NWibZnAuuoSjH2G
mDM3QVPMHgRm4NYE98JCzcRnIbcfDhZq1do6vIrZAi26NAaB6a0wYLHIUuud
WkPOP5oRem+ifM1U3FZH7Di+sVFg05RjTkscpbFrb8JkHokHLQXREU7rbMFs
O2W2jKjdwgktb9jxlW0k3QEktxvK8F1k8EwdqFrfIACBDU+nA/g+yH7mOIEJ
ffKA/+e//Xd9tdvd2kWEXbwcV+Ljr2IRhrKN62J7p2f5lNXZHZOnDxmWRKwU
04XlDawOEaC5xJACD+N+1AzMpPQCf8Tl2Vmsa3xTkQ3Q3fF551Fao4qCaIVD
pY+7OWkvZBCGtyCcKWGVIXB6BvPMSrZbgmXBYHUUMZ/DEZsSoXLWTMVOQnhL
kd9YRF5n9IKmxavF0mRuKQO+uA8zW6KabfJEn0KwjiCv11kzcKitELYmJ2Fd
yNky6KZ/BSiAymkCIiKWFDHOeEpkXUQlT8cNgykDx0DxvAB+ERxh5a0KtDjT
woWmwHpYZRDWzwLV8PuBCctiyjQlVY0lhFpIXoMHwhhBAmK1JK1vM6uYETvt
u0mC33oAKIsU6tFySK+/WxE4vMZDG+sFmFePuGCvVJFk4tLIecmcAgGHXS5L
QJ+SJT9v+s0rFx4BdVTBGjinwgdAqK4e9PZe6dXw+SBVERwlQA0tUKCzeJIi
4XKevkuz2/Tek8Ggig/YnKyASC+8KZxvFDnbDHvj48qVSi3IruUElHhkpBZ/
odZ9Ybk5UVTGLIz4fzZJ4Xtrt+pTUQh1tDaMgsi7u1jaG4Su6AY6Yld9DekN
pmSV82qKXroQRGZlibHSzeo986fKwLCuQqKRLJ0kCz9YJK4P1oJZOKRuDiPr
QH5GWwlJjLy1hHUNItEvACHJ6U0PAnbdSCqRGsXsTU1Ls/k2acZlNswSY16G
aWroZTrNkNYFGKa8FNw9SG7FEON5KhLP2aXjOIG6CEY7y+ObcLgIkDkfgx+q
WhZNWlmX1efQLKf1ydtVdhNWSx1LRHuN912fmu/vnritp5Tn0133HdNgbetK
LLcDeRFL+px68OMlN744BYrI7eLH+IzsY6NeIAnY8/4/ODS0vzSaiByCdjph
8isy2SaALCV1iGlzTCyoNPkNK3dmDRPiNrbMSnncljYfkulUWzKMAMI8NflI
FgRQFInFAmGVs9S6sUU55GHQ/bqZWUoQ/wmR9STJBiSsELdkz79x1pp8Ls8d
HPo5CMsgMwE9TEELlCow/ywKDkGRQvmGtyIRFrLfiW/eSZD2HvzkJh5FRok0
kSNRhaFkGQCgozSHVHWi5Xwy520kqSzbjXOpLFlBQ2Q+A8oaz9fTJNAnLhD2
ExScmkjal0lwYcZuv22yWkZBTb51rLCsCT3iizOE22weoWRzWhcv3PYSePA/
YpHzhzmp5ffquf4NkedvoYT36Y++vnxxotvEFoSMWDGuvtxQz6nRaySBc+N5
tUKsfgcZrxC34oQMLtfhpldZGgVZHsBH8Slios+vOmLtcWv58dtcIhZ6qTf1
N7r3Mf3yLbd7Qas0NtKUx5LeDWXI4reLDQl5EskIQHgimIF16ZnIyG1Htxc1
Zc7pkNK5qbZAn8ih/K/0o9Q3/1xmwQBJpVMykEbfiq5fVwqNw+Bh+qiCENam
CwfU49plZgnal+Ee7vlqzfJcuf3Cw2WP465hoRjLRLwOEpIETgdG4Sk8O188
ZF2jMxuvUaiHcCwOiZWYwZ15aOIhsJDSkG3qbNwRK1y5tn4z24gDaBUsBhAi
Zdp+Q7YmEJcrM5GxobAsVkfYx9KxulNcWrfmB+R9sGdTFBUC5eG97Lt5CY/E
OEh2J5z3Y+jE5hepvMoNqydn7XV3TUhHjF1IJUiVCpGyig7TEurk7OYE/o82
/ZpmPnMmhTXKNzrKmmtINJjMwzwkAeKZ7fx1LInX4F5l03vH4eIk8R1ORZNe
2iZ8aVaPFQzFgVLaibMZIcYsG1AaJsK9CAA4LuvRsBC5bDLlYoOd5YRdgwIX
2JXJG4EgGe6zCEo9i788EsFFWtLIblgRpGYo9kxAqZBAmXU9E86PTdatzQoX
gwwBDtYDjcJoJs+YE105FtoknI1UHTVGPQaNXCNHK5VIhLfV8hAp8mDJwMH7
hXD6kO1bbxdjF9hxUHBj9ktD4XY+R6IRgEx68JzjA7XwZLV5KxeOaCNjshOZ
1RHhGTRxDKsur5XFRNvGro+GUKexA99iDsFXebxhFwPb2PbZzCrf7W7ts+dF
OpCoxl53a0/6wRTw9kJ8Y0jfQA/YNDdRstiwARzZT5xgAXip155+Qb+L9BCt
drVGVtdph6LTHvmWNzacZ3ivZxogT1VptE7JqnLgq5cdX3cKViUzgAMAuVyR
4Klryyb2Bxiw7D9VXDQBTYrojr6fhrNGpL/udDAqE5q9M5quiSGS6UB/tMMB
O2yiX2xIfJpFr5Q2kj1kozriknIOCt4OLvZB/CkzMcm6fttVb+BH8RznfsTO
MwTaRp0fOnX+awLS4KaaaYf5X6VDeq4Bw7+FqfA2UOBTnBNhwJSKjoLYUwp/
MWdRoYxWUF91Jsb6oO4VYAPFJktVIU1Gjh3gGT/yQkKyGLk/VdWOu1FXcp9c
GsXI+M19/BmVqD7kJCOtAKXMk4qPNnTHy+tlO0Mcqca6D22pynQGFlSXE0hx
UmRWs1e/YwqgiqU6IZYyCx8GSaZWNbUIwr0Ov+FAGEUAyOMiM5UyoD6GE1nj
UA7YhgkiV4YC5mkGYslQmzjnl8SFcKtxJk4IlNfKksyiPAYYHKCeV94L+MCz
2ZTji4uhCcsx+fjcYxTNkmwhdODXCJl4yIzrc8T0GHnx0wcS+1w8sISU5fx4
WilOQumq9qWPjvKa3dw37GiFsMhQXwg+zALuNjKuAOf8leQmEQUt9g6UjI2W
zrGqjm6XrFFYofB2pVngZd/cN0IEAKzaZrUNgAXgEKkhbON2NFU5NtiXkoSP
bqJmlg8bgEiPp9UZxjPIkLjUNq8Z7MpPCbKMk0ueEXeY5xKiQbQ6wfo2vVhm
45EWJQFhl3W/WcWGnUcQ+gFcXnjIOVbQY9QjyZGcpF0zIqHQSebxco7/hmIT
03CfCoeSTxLqNqr3gvlM+DKJ58dkBPF3U4LDZdgYUiHNeNMk/226opBgu2/S
Amph+1aHW5tEM9c86PVtIJzx3qj9Wvre5ZGZHoId+h4aMYo7Z6OuQc7my6Od
7ae7O7vms3oEc1MHu3293Tvo0K+kCmzpTUXNWmU46e9MZjNUhnZ6W71esLXT
v7zoHW5v91pkDHIhzKaohQBgi8ZeqjA0hVZo0+qYL2i9UfX4lnRrUo03NaHo
G1Mtaf9Fsxne07+tcUwGqvzJxxHA69LqeC1pNOJtaGoj7aQbZuKis1uuZdp/
23loqCIawjvXGMt+qrwONm0AMhq9JF2aCXlT8/rt7I4GOztjfHav7mtVQWsI
+vHqIFsMdOqIlyUC6JWIETnLbwY3cTYvkgVEt744eaM5MXfn87dvWWRLaUpY
xMnCCUmTS2l2hqrvY2M8s3eYg5pWnlVyYkn6ESzPHtq71M5tXvqPckkCdhuL
xybJsncC/vIW9XQZf3gkSnzAtu3/R9+2m7tPt7d1LBXJhDCH2Xc2H9Z4KSWM
7BFDNOqj8B/f/+fu/sftbqbNv3F71wi8XS3Uht30az3ZpVgihXWzcEBrpUmn
fGvJ+tqd+w4EYmJ4TofOZU8QKa3v0MBT10lRP8+OBRskLjnYyjksngXYUeVi
ZsZmjxUniJMxmENXDY1KtNKZ/rWJGeU2k8I6Jjiohvjh2gjgwsvAZOBVI4Cn
OYDnaiGdXhR7VeM0llqdmOa55lOw4YUtzbcp9J4lXDNroaFydGpmyxWNfojs
RdTMpRKT0INw+A7xMatY43fFqn+JYm+M11UXtvK883AwVDLH69jjUQC1eKvN
ENoOEScwXAcSZVhYvX81Em+tfxIVGtQ+z0gX5UMdJP2IY3/ACDN/3vhBlczl
UtxUVVIOhRedyXAje24DrBG2radxUXVggWsmQi87KdqS5yk0mlFvocyztdF1
FZpIWeowsd2uj2MxkFyFD3+kaoTmvH7eRZHLx8wISfjWX9olvHNCxBMakoOT
fFQG0VluDKq7J7BLYCkRu3jbUNSxyPOUM4KF9BIuyR8mWRE1qdB45RL4jOBV
QCTIBERNaGdImgxRgHV6ErHZNE0enlOdRYNw4W7rQlm4LmUrF8881ywSNATA
mlND2AD9vmYGQOJbWnB5qs4M+2LBdeZnvL09O9tgFF7YKSzh0M5BqXVm5tCc
UoUwOuKMlUeiWZ7TNK/ad3cNM/B+g4zsN2lkRZ/d81Ub5J4L8/TXxNc8DBK4
yBIniKA6m2l2ZROnIA4i6+eljczzYDux7jRlYD6muX1cTQxrW4PPlrktZ88S
FBB2Ti5U/uOhwbs9KoIonNibBAZCk51sCjeUTYMS50JtYEl+RA/iuBXZxgfk
2TRvvDBInPJOhrtLNqA45g0lDOuUwMed2SDE0yqbTIjY+ITcx4DDbpFmR/My
Wa453zOhNVM7LztDYiQJMkLkJBssOxf0XeehlUNRPmXo1gGO5UGukz37xK0p
ApNSRbjQ0R/mLky88FJ3vMVXTVFpNAwWuaslH1fiGy2lz5tcMXv3c7CWqhpd
/qpTU01CJ0uEtbvQq/gYSiZCxS+Q/lgF2JCxo7A1afO80y6jo871TuGMhTS0
eTj1VJsPqHMEAKpO2VEpefTsfAsFPH/nSiSCy+NMLiNsiGysTM415w/eitPW
JDwMOcSHKrpV8+CQT+gCBsKXebff3TXSre6JWbAL2ajkkzycuThQU9GRtElT
3tNVb5vZMfVCjJXxF1MLoMTtpLMB6Va5kLQk6GMIcbpZJjcF10JcflwlgHLl
cDVulSGNtL/93QBFEiNhgDjm5+j1UYPFrwpjN5/wUX36lLS0LO9rYmBIKcyj
WYL8DxsPrxy19IRNicqHzkuOhiBu6VWeERk+kkqE3ATjhF2QOKoScpT69BdB
gBQhOQwtsMcvtTlyfWyeygFexcancnYgH2lorSBI5iB4/kg2JzZpMR8EDopV
+TKqAteF/eRUVDeYN427X6yGRmKwxgNLOv6CLLdGWoL4wFt+jd9ud5/5sT2x
UIIbpwg7CM+qZ40spCrDaN99v4gXyL6RRJA+z7yezWTYCbM9E8eV3G2zTUhh
U0pSQ/hzuDdMLZVfcEjgxA0xaA037sFLG+nzv7Z/5i60AbJhHDp5Zj5zB4BY
16dSKxJFANag+ZhG5FAE00yeJUmUo2Ujw7xncqg9LCt1XqWJoOuqOMaafyIX
OTZQ2hNhJNQkqXfEhUTsoggKUd53dgmIkLc/2WK9d/uTbe02srilqqiEp2/B
byTiK0q/zxA6kZILE9MDg02JrEupeOMhXb+cASwHj0y5qqJEVya+YXErYj0j
3jidglXbkjHLnCG+FC87c31UGrD+ghSLPOACh6OL47MzYmkcqWuHwQ9y2NQP
ZGNooyT7oVFpjjMqSRxKdMJM1kQYva6lUzKiR/EkLiWrNdTXixlJ04DgxYlZ
4p9HZVJYDkmf0FffEAzffhPQf7eCw28/vuqqo6JOWbIcHcl5cxobF9jHtJrd
VXk/bss1CaISzMYsRqpoRYsflDDUYebLQ1lzjlan1g2N33L7yJw7Y0KN9pta
kBJWv8TobJUTgq8ue21Ve7P3vVL6uOTTe7h2wZnTtvS2xkJDKYWqUpl+1I73
6B85vUyv+PlRyPASPMF/urTTV3386A/O7LLLZZ4od9pVsE3vxS+66ssr/zCO
K/v05x9+sAYuK2NXwNXDKV5CHB8M1z+kov8RuHbovXP3LsOF41Cumk/rBYb2
rDwQ7OPl/x+Kr116X/cn1+CC1/Ivf+IzbP7yp22HsRVFgn/Dz8OQ7dF7Vw7z
gRh7YWv+/66fh+Hat3BxEf8SXFXd/lX1lOFK/PLtdq34e+MfAtlTCxkq89dB
5iqXryrIluvIfzZ4D0GGDNof16XGArLlTFh6+ndksK6Eq+PSVn+UQiZSm63b
3XLpU59Lrxc7vhYO7/vaLKlV6rrJlfr5SnZ9iH8zFdtoZ3l0E0e3Dc16b4Vm
XdfowONwypJR6Urk6UK9eFcdremlq0iWCNiXIvkn7kau4aB1JCKZRoH8yu4b
1rLFE0Z8mqTm8DqObiT1bTAvFSkwQzOMcfqu0De4CNLpGjUhiSPfolLByB5E
JIg5K6Q6tlCSTwvWa5PwPYFjj/QlnKw1TPisuhWnCi5bKUgF+futlOWMsH8n
M+X/BfNC4PZqH1aokshp44OEbKZyKFqU17RjvaySi8ZFWjZ0JrUtKQ6AF0X4
P02a/x9Mmn8DPZ6k4z9eUXdCl327pKLP0zRKAv5LjvvlXNYl7691w3Fo7/E8
/7pU9Q6IFdE6fFy0Pi4vIVghWV+BVtnIoVWAx25pk43M6cz2XEn5JGC7yDiv
W1UvRUstyUXeDwG7wLmGYL3NZTB+actPfs7i1F/QIObs8uYZwZ8gK4W+9CLb
m4809ZejmoxbELjiq8fapB8k0bhs2XV6TSpHhaQPHhurdNc3ma33ir9NrTDx
6qDVxXxQ+i8f6hSsXgRolaNR4KPXm0dKiWJIJLXi3alhdo2wB96TpQ8zs10/
lnQDBSMrQyX4xg9a1oqdzhph4BXfpqTVKvV2Pkji4tpPpbDCsbFStf5rmfTM
EeX4DD5SBotkHYK28sIV1eVuizGMqZTRkyJDEkCpl3k4EUWmSuJYBp0dOHwx
ienXc3WMl3vg/IPQP354zDfftGpEBGLpat0+IgkNpFQlYRXx+lUoenko84kB
za8HXTEUraxEffUv5b4hlzkiYZgSqdhSQb10Gh5jlq/J+pxvB2JRyOVCtVuC
NqBJUA+4fUvXlkwOtA6T4BL3RRyR1kqiMC+rL4WEOGI6x/kmPOKbV6/evAbx
4+Aoc4gep6eaBkJSR5whvmnUqGFNjZJ7wN5CAypkk/iahPQh9kotILCGs7r0
wLDR3gYzTJL+iqhDa1XYobUu7qB8MdqxQS1m3I/d34QAx/nphqrMnhZh3vH3
NWZPU0xbQBu+tFX83DSlf5nR/KjPTlYI4Z/Bu4Ml4fLiZLtmUDMTX8e06zjm
s+HxfWzDna50tTr1lCuVe3v73e7h4aE9YtyzNcKq2Hqw8LTybauWS7Fd404U
VbsTZZgl82nK6+cw29KcPJIgO9JIZHbIWqeqanxkcFz7zHJ44iXf/LMEzzhG
Z37ta3O1go1Z2sIXjt3xRRSE1oiDd6a+ydxlp3cOrIkubo9lvLSI0O11W0aQ
0IcummZf3d+3HOVVzzqyx67DQntJP97o3XWbUCKLdYPWJQvV7GkupXJum44j
IXPDCdKHlDtGMLiU0wkvzKGAd0/MvD9b/WN8FlyNN4rfezXcAC3MyRwnTVcv
V+x4c4T5APcXn5pLpj8R9Q++nbHixESWZ+iia+4CeF86l7yDhY/YC2dlncx9
k1zOP5zzsZMiM8iCsEcLNSp6zkrtTtuSEjajafJRPNxJZEtbJEzuefaQ+Kb8
ExltMSVOWzGGB5JMsNiBRwmSrRA2weYaQyOh5jOcjFHw3Ot1Py6MIk0axGK2
lbGAmcocTcPwVqYWzLr7uuqlnCpSg8WkidkBPPR3pBKGU7UKtzjunGuUqiHd
o6vanJfJXbiatqoTZLxhscmSW3WUz4BPzFD2wp+m6QLgwlE2MzyJVsK/c4XU
ga8KUyHEw/IZmrDXcBBelXU0T8r6nq+OBgSDmmZFae6FsphwO9FOhBmqd4GQ
fzuJZOpm08ic7iansRgjHHkbjHBzbhbyjYk2HXWxpe2d4/nYXT+Yoqloo7+/
n5sCdckpU2U0vDZ3T0gChyQ6F0t70W1D2eiknWTzfBipE89ufemuImmfn7zc
wG0T+WjMttSJzYe/sGpkDSMWL0drxrW7n3ekXVli1VzG7vsgcLVWHi6UOYI0
idJJySkrPahoO8ZTKVnmUeK5826jJAnMNUG1nSx1mS/gtDnmKEtJmhVOqqYt
tfsUntHAXrHorgaxT3b54DX/NDS+huury5fBgb+GKGj4HhQExWNno8ocQ4K6
DyamN4hpvxNNVr3o5V4U9aJf2LuOkuaZscKrbU/m86ErFucUK65T5cwBm1Zg
b/wsnrmEYy7c5isyrEkPB5LxnPIsbI/4JHezqZ9H6TDEBIv079w6TPgwBcM+
xZtnmWpDfQv0FSfnXvU1tKOgzIKcU4W8eEYrKXPk6kptrj31tXFDyyguSNYu
3BGwtc7M1ZUeZx+byxZwz63ElOMiSyqkrQGGOkHdP31OzBkub3aufnl+prvd
rn57cgZ6hf1LaGAciWuUr/Lje8OEFWmXA2Y8cCmcvWZBQQv0qgvc4MJgQg1D
AXAAVg01OHT3Z6Km3tnPR80aYFaj5vzLn4cad1ixfgw16TxJrnRFY3IWVOYJ
bVtB41Xw1KBthfMya9FWjxCUYH9yagsZhPrNncVkPw54y9lj7LCj6VtYA667
ETFyDim4s+3JcnRqhpnAMoJeXjgEiUG6FkWQTaIF1PYkc5iB7Ejvbkbj2JCD
Cs1JJSanX9ncOvhlG580D6EO5YDF3NwpZ0/0zHIFhUGM/myMXGeBzboA1oFi
YZDqDJJ3IaS2O8HZrZsrKgslVmGW266ZGD7gWv4NMqwD6c/0k/3uzkH7myqc
22Gy6eh/asRRv91QVSN7D0mX9AfaQboF5/NR8Ptv77Y7B/ftwPwJRzQ/2fi4
pRr9URe/xGHSfc1MjVgk7nvBJubi8IxMeJrGBhccSdLf+Vcvfvfd5Rfnp0cn
3/321XcXl0fHv/nu4uz3p5/tbfEPz4wphPP7Xr+5PO1r/zRxI0GB4in8ZNYz
w153e3rCLe7CeDEvlR+m2TbHr1SCsMNqIB76klN7khOHUZgrbvn8lFCO8nQD
Y62SGnS8LzmQYSMEyp0XK+oAyPM2Lq7lSGvW0zlt2MsWrnUJxaTKzpVogPRk
NCaWb9Mokj2P43lgrpijiGw6P1e4qUbsaq+7Y2874EvD+KIURjkXmTeu0MXe
NFev4pY0CfDxQeDiuasiI8rdrcgqZyj100xu7Sqc5c8SDTaqY7LgL1JffXLK
JEF44l+fvuzqowRH3eBeDtCAr3R3vEAZKXYdZRBD4sCeS8rFB1X4Jk5rxps5
aGD5+tZrdjLQfpVDOZb6kdzYikxEH6nN8AbroXCbY5Sb+xzdqYLmVJOuvogi
m8nPq9M6qQYlmxTRSDMk3z/mKHtHbuv0V4fVDmiL+JcvusENzMxU7T1BqlJo
3dVBLlRkugbxuGOI1pWqG0XVaGypYu0R3K1cBCjXL9mueR9CYkzZgF1xRLDZ
MiP//okqSmILQl0VLn9ymk7gsA4clo3UaX1BE8/gilGeVrtU/Q6eidPyO/aD
bw2ncs1kEurkQPf2G861JyDa9s4B3+540Ft6ywp+u2cuf9T7vcbHRHfVWzTY
2z91bwGV/XBvxYd73oe7B/TpMf3vJT6Uicg0PgiHL2F2r0Dhiyz9nmynD0Pi
OAcS7Sc/B42Po/ID0LkOpftPe7UWgNN28HRNB0991Pb2X+6f7h/tv3y6R109
qaYoE/wQ/H4RDfLotolf9en8+V//9a//86//46//69PN+fPGcdTu3O1IX5FI
vfLUVZLUuTukjfiu07gaSpI5qh5oA/9sQSi3Vq/eNdJMWxYc+h1tf+4iNpdx
Z00bWcid9Qu5eikP6vsAa3HtyqD3D9Z2cuB1cvL06PDk6eEx/X+P/n+CTtys
TbOXe6u6Ii425TKNdm/b4OWJxKxqd4i6UPXdExdnVupNqodRzm6ZbEgKhJFV
pTuvOI2Qamb0bTnAqd2SaHhrQ/kXk/5tIfBu0xtauV1WhrZt+rA7cdbdm3xp
7Gnnp19fOsp44DQi7+gmuCsL7z7QuKips14CwGfaXYGI6KHeat5AKAe897Xc
jLjF4QG+s0+u2JOL/u7NPrVoDWsXxi6h89cXb17rbPA9zoNbhdrlWtuOkX18
+Je5EcDvhRaUpebSye77NbWLzIljWE9safFtgh+0qq+kGseddsfRRbnPpeMu
JzE3l7pqxppPQzkP9EN4MYkJlaW2tojGpJx0lZ3OwxTGu8ZSS3fNfFzUpSVr
Xp/BMnCK85625Dovq108BIYZGJlTcsM9NjR1sim+nVlIS0y2fpUHJJXcxfKq
GmXaYdK38kEf0WgVnpW7xc8RzQMg46y2eWou1nB3s/H5gr7XiQn+oYI/JvAm
Yfu06w7TYkFSzd5aMyZ3jU8+JdUTcxrEHLCUCj+EtkjsmQvWh0IQLBJxQYMF
h9NclI2C0kY4SpcbsNMPumXjYDixtd6jVrgsVJnNjGotlpKj7Q85DFTum49x
quZtuFBmDWTdCvFV2+Pe2K7yK3aBa3vbXQ5D0pRlfNi4qV4iLTYXpA5wnqN+
1WSK2HM+Z+aYgXbzih18I6XYfo33wB2SoWSiEWKOpZeMaM8t1+wXxzHN3oJy
SNMcHMoXYuujIUovk2jEOQ+4bIFYN4fZoxGf7Xz3KqR+SImBenIdTu+d0/nu
NI/f6a/jBFbKfXWGnMmtYEag0e43STgv1Bdkn7+LvM9/HSKC++t4+tO/ptEP
3MUwC7xe+KiKPEG2iDWorZFBqmwt/iADHV/nRE8kpfTRtPjpz0VxL3d1Yw7D
TF/GOIzRPjvKY/2bKP/pX9IopWfKQPWKyCAkwjvHv/moyPDSnN2M3GQTAphK
GkDWuDsaN5ffvczBnoshbcowYQ9DbPtAvMr0w0fimh24IUnGXNnAp2UcnXQs
QL/OCJpfh9GELCTXDQ355u3Fydm56a0jxxe4I04GOV+1pSDcGUlp6dNmozzb
lplUs1C4etML6TIc12Q4Zrdh6q3hCQ2jT2Gd8kN7B7nJAXC0BWK7tC5SU1Bf
La6X0VyPr3LlMPpzp57Y81qReVME5jEyAmyKi5EvCSkm9ccmoUYhoaaAnODT
GhFSS8xpMZbyJDrLwRM7cFw7TMmePIdz3R6+DC/mUxm+t9cF1K54Mw6hSzC+
RDhrNVrhZ6N8vXNs0qoazt1jZLV+bfTWz2nJZ+bAFjMTc5wVTrJCHLlaDpNq
nWdFERB2wtT0qIYZp5eJx0AOK7InFHPKD6rqJQtbLo4XqvhNguJnSxfYAkdE
a0iCentNmnE8k43IBO9Km6Dc4eSVrKAllowP7FPCpj756c+kit2zj4N9jfpL
2rjJ17g0vq/r5y3U7g9tHjOo2PX4fwEUKobJWZEAAA==

-->
</rfc>