rfc9290.original.xml   rfc9290.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY nbsp "&#160;"> nsus="true" docName="draft-ietf-core-problem-details-08" indexInclude="true" ipr
<!ENTITY zwsp "&#8203;"> ="trust200902" number="9290" prepTime="2022-10-18T15:04:38" scripts="Common,Hebr
<!ENTITY nbhy "&#8209;"> ew,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocI
<!ENTITY wj "&#8288;"> nclude="true" xml:lang="en">
]> <link href="https://datatracker.ietf.org/doc/draft-ietf-core-problem-details-0
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> 8" rel="prev"/>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 3.1. <link href="https://dx.doi.org/10.17487/rfc9290" rel="alternate"/>
2) --> <link href="urn:issn:2070-1721" rel="alternate"/>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-core-problem-details-08" category="std" consensus="true" submissionType="I
ETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.13.0 -->
<front> <front>
<title abbrev="CoRE Problem Details">Concise Problem Details For CoAP APIs</ <title abbrev="CoRE Problem Details">Concise Problem Details for Constrained
title> Application Protocol (CoAP) APIs</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-problem-details-08" <seriesInfo name="RFC" value="9290" stream="IETF"/>
/>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>arm</organization> <organization showOnFrontPage="true">Arm Limited</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization showOnFrontPage="true">Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2022" month="July" day="06"/> <date month="10" year="2022"/>
<area>ART</area> <area>art</area>
<workgroup>CoRE Working Group</workgroup> <workgroup>core</workgroup>
<keyword>CoAP</keyword> <keyword>CoAP</keyword>
<keyword>API</keyword> <keyword>API</keyword>
<keyword>Problem Details</keyword> <keyword>Problem Details</keyword>
<keyword>CBOR Tag</keyword> <keyword>CBOR Tag</keyword>
<keyword>Language Tag</keyword> <keyword>Language Tag</keyword>
<keyword>Bidi</keyword> <keyword>Bidi</keyword>
<abstract> <abstract pn="section-abstract">
<t>This document defines a concise "problem detail" as a way to carry <t indent="0" pn="section-abstract-1">This document defines a concise "pro
machine-readable details of errors in a REST response to avoid the blem detail" as a way to carry
machine-readable details of errors in a Representational State Transfer (REST) r
esponse to avoid the
need to define new error response formats for REST APIs for need to define new error response formats for REST APIs for
constrained environments. constrained environments.
The format The format
is inspired by, but intended to be more concise than, the Problem is inspired by, but intended to be more concise than, the problem
Details for HTTP APIs defined in RFC 7807.</t> details for HTTP APIs defined in RFC 7807.</t>
</abstract> </abstract>
<note removeInRFC="true"> <boilerplate>
<name>About This Document</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t> "exclude" pn="section-boilerplate.1">
Status information for this document may be found at <eref target="https <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
://datatracker.ietf.org/doc/draft-ietf-core-problem-details/"/>. >
</t> <t indent="0" pn="section-boilerplate.1-1">
<t> This is an Internet Standards Track document.
Discussion of this document takes place on the </t>
Constrained RESTful Environments Working Group mailing list (<eref targe <t indent="0" pn="section-boilerplate.1-2">
t="mailto:core@ietf.org"/>), This document is a product of the Internet Engineering Task Force
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro (IETF). It represents the consensus of the IETF community. It has
wse/core/"/>. received public review and has been approved for publication by
</t> the Internet Engineering Steering Group (IESG). Further
<t>Source for this draft and an issue tracker can be found at information on Internet Standards is available in Section 2 of
<eref target="https://github.com/core-wg/core-problem-details"/>.</t> RFC 7841.
</note> </t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9290" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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 must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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="sectio
n-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-te
rminology-and-requirement">Terminology and 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 der
ivedContent="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" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-extending-concise-problem-d">Exten
ding Concise Problem Details</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-standard-problem-detai
l-ent">Standard Problem Detail Entries</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-standard-p
roblem-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-privacy-considerations">Privacy Co
nsiderations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-standard-problem-detai
l-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 derived
Content="" 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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-content-format">Conten
t-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="Appendi
x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-language-tagged-
strings">Language-Tagged Strings</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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"/>.  <xre
f 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"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-detailed-sema
ntics">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"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-examples">Exa
mples</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendi
x B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-interworking-wit
h-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="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
<name>Introduction</name> ude" pn="section-1">
<t>REST response status information such as CoAP response <name slugifiedName="name-introduction">Introduction</name>
codes (<xref section="5.9" sectionFormat="of" target="RFC7252"/>) is sometimes n <t indent="0" pn="section-1-1">REST response status information such as Co
ot sufficient to convey enough information about nstrained Application Protocol (CoAP) response
codes (<xref section="5.9" sectionFormat="of" target="RFC7252" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.9" derivedContent="RFC
7252"/>) is sometimes not sufficient to convey enough information about
an error to be helpful. This specification defines a simple and extensible an error to be helpful. This specification defines a simple and extensible
framework to define CBOR <xref target="STD94"/> data items to suit this purpose. framework to define Concise Binary Object Representation (CBOR) <xref target="ST
It is designed to be reused by REST APIs, which can identify distinct D94" format="default" sectionFormat="of" derivedContent="STD94"/> data items to
suit this purpose.
This framework is designed to be reused by REST APIs, which can identify distinc
t
"shapes" of these data items specific to their needs. "shapes" of these data items specific to their needs.
Thus, API clients can be informed of both the high-level error class 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 response code) and the finer-grained details of the problem
(using the vocabulary defined here). (using the vocabulary defined here).
This pattern of communication is illustrated in <xref target="fig-problem-detail This pattern of communication is illustrated in <xref target="fig-problem-
s"/>.</t> details" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
<figure anchor="fig-problem-details"> <figure anchor="fig-problem-details" align="left" suppress-title="false" p
<name>Problem Details: Example with CoAP</name> n="figure-1">
<artset> <name slugifiedName="name-problem-details-example-wit">Problem Details:
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ Example with CoAP</name>
svg" version="1.1" height="256" width="288" viewBox="0 0 288 256" class="diagram <artset pn="section-1-2.1">
" text-anchor="middle" font-family="monospace" font-size="13px"> <artwork type="svg" align="center" pn="section-1-2.1.1"><svg xmlns="ht
tp://www.w3.org/2000/svg" version="1.1" height="256" width="288" viewBox="0 0 28
8 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="1
3px">
<path d="M 8,32 L 8,80" fill="none" stroke="black"/> <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 48,80 L 48,240" fill="none" stroke="black"/>
<path d="M 80,32 L 80,80" 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 168,32 L 168,80" fill="none" stroke="black"/>
<path d="M 200,80 L 200,240" 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 240,32 L 240,80" fill="none" stroke="black"/>
<path d="M 8,32 L 80,32" 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 168,32 L 240,32" fill="none" stroke="black"/>
<path d="M 8,80 L 80,80" 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 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,128 L 192,128" fill="none" stroke="black"/>
<path d="M 56,160 L 192,160" 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 " f <polygon class="arrowhead" points="200,128 188,122.4 188,133.6" fi
ill="black" transform="rotate(0,192,128)"/> ll="black" transform="rotate(0,192,128)"/>
<polygon class="arrowhead" points="64,160 52,154.4 52,165.6 " fill <polygon class="arrowhead" points="64,160 52,154.4 52,165.6" fill=
="black" transform="rotate(180,56,160)"/> "black" transform="rotate(180,56,160)"/>
<circle cx="48" cy="128" r="6" class="opendot" fill="white" stroke ="black"/> <circle cx="48" cy="128" r="6" class="opendot" fill="white" stroke ="black"/>
<circle cx="200" cy="160" r="6" class="opendot" fill="white" strok e="black"/> <circle cx="200" cy="160" r="6" class="opendot" fill="white" strok e="black"/>
<g class="text"> <g class="text">
<text x="44" y="52">CoAP</text> <text x="44" y="52">CoAP</text>
<text x="204" y="52">CoAP</text> <text x="204" y="52">CoAP</text>
<text x="44" y="68">Client</text> <text x="44" y="68">Client</text>
<text x="204" y="68">Server</text> <text x="204" y="68">Server</text>
<text x="88" y="116">Request</text> <text x="88" y="116">Request</text>
<text x="248" y="148">(failure)</text> <text x="248" y="148">(failure)</text>
<text x="96" y="180">Error</text> <text x="96" y="180">Error</text>
skipping to change at line 119 skipping to change at line 236
<text x="144" y="196">a</text> <text x="144" y="196">a</text>
<text x="172" y="196">CBOR</text> <text x="172" y="196">CBOR</text>
<text x="76" y="212">data</text> <text x="76" y="212">data</text>
<text x="116" y="212">item</text> <text x="116" y="212">item</text>
<text x="164" y="212">giving</text> <text x="164" y="212">giving</text>
<text x="96" y="228">Problem</text> <text x="96" y="228">Problem</text>
<text x="160" y="228">Details</text> <text x="160" y="228">Details</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center" pn="section-1-2.1.2">
.--------. .--------. .--------. .--------.
| CoAP | | CoAP | | CoAP | | CoAP |
| Client | | Server | | Client | | Server |
'----+---' '---+----' '----+---' '---+----'
| | | |
| Request | | Request |
o----------------->| o-----------------&gt;|
| | (failure) | | (failure)
|<-----------------o |&lt;-----------------o
| Error Response | | Error Response |
| with a CBOR | | with a CBOR |
| data item giving | | data item giving |
| Problem Details | | Problem Details |
| | | |
]]></artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>The framework presented is largely inspired by the Problem Details for <t indent="0" pn="section-1-3">The framework presented is largely inspired
HTTP APIs defined in <xref target="RFC7807"/>. by the problem details for HTTP APIs defined in <xref target="RFC7807" format="
<xref target="comp7807"/> discusses applications where interworking with <xref t default" sectionFormat="of" derivedContent="RFC7807"/>.
arget="RFC7807"/> is required.</t> <xref target="comp7807" format="default" sectionFormat="of" derivedContent="Appe
<section anchor="terminology-and-requirements-language"> ndix B"/> discusses applications where interworking with <xref target="RFC7807"
<name>Terminology and Requirements Language</name> format="default" sectionFormat="of" derivedContent="RFC7807"/> is required.</t>
<t>The terminology from <xref target="RFC7252"/>, <xref target="STD94"/> <section anchor="terminology-and-requirements-language" numbered="true" re
, and <xref target="RFC8610"/> applies; in particular CBOR moveInRFC="false" toc="include" pn="section-1.1">
diagnostic notation is defined in <xref section="8" sectionFormat="of" target="S <name slugifiedName="name-terminology-and-requirement">Terminology and R
TD94"/> and <xref section="G" sectionFormat="of" target="RFC8610"/>. equirements Language</name>
Readers are also expected to be familiar with the terminology from <xref target= <t indent="0" pn="section-1.1-1">The terminology from <xref target="RFC7
"RFC7807"/>.</t> 252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, <xref targe
<t>In this document, the structure of data is specified in CDDL <xref ta t="STD94" format="default" sectionFormat="of" derivedContent="STD94"/>, and <xre
rget="RFC8610"/> <xref target="RFC9165"/>.</t> f target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp > applies; in particular, CBOR
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL diagnostic notation is defined in Section <xref section="8" sectionFormat="bare"
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO target="RFC8949" format="default" derivedLink="https://rfc-editor.org/rfc/rfc89
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", 49#section-8" derivedContent="RFC8949"/> of RFC 8949 <xref target="STD94" format
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i ="default" sectionFormat="of" derivedContent="STD94"/> and <xref section="G" sec
nterpreted as tionFormat="of" target="RFC8610" format="default" derivedLink="https://rfc-edito
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and r.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/>.
only when, they Readers are also expected to be familiar with the terminology from <xref target=
appear in all capitals, as shown here.</t> "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 Concise Data Definition Language (CDDL) <xref target="RFC8610"
format="default" sectionFormat="of" derivedContent="RFC8610"/> <xref target="RFC
9165" 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>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="basic"> <section anchor="basic" numbered="true" removeInRFC="false" toc="include" pn
<name>Basic Problem Details</name> ="section-2">
<t>A Concise Problem Details data item is a CBOR data item with the follow <name slugifiedName="name-basic-problem-details">Basic Problem Details</na
ing me>
structure (rules named starting with <tt>tag38</tt> are defined in <xref target= <t indent="0" pn="section-2-1">A Concise Problem Details data item is a CB
"tag38"/>):</t> OR data item with the following
<figure anchor="cddl"> structure (rules named starting with <tt>tag38</tt> are defined in <xref target=
<name>Structure of Concise Problem Details Data Item</name> "tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>):</t>
<sourcecode type="cddl"><![CDATA[ <figure anchor="cddl" align="left" suppress-title="false" pn="figure-2">
problem-details = non-empty<{ <name slugifiedName="name-structure-of-concise-proble">Structure of Conc
? &(title: -1) => oltext ise Problem Details Data Item</name>
? &(detail: -2) => oltext <sourcecode type="cddl" markers="false" pn="section-2-2.1">
? &(instance: -3) => ~uri problem-details = non-empty&lt;{
? &(response-code: -4) => uint .size 1 ? &amp;(title: -1) =&gt; oltext
? &(base-uri: -5) => ~uri ? &amp;(detail: -2) =&gt; oltext
? &(base-lang: -6) => tag38-ltag ? &amp;(instance: -3) =&gt; ~uri
? &(base-rtl: -7) => tag38-direction ? &amp;(response-code: -4) =&gt; uint .size 1
? &amp;(base-uri: -5) =&gt; ~uri
? &amp;(base-lang: -6) =&gt; tag38-ltag
? &amp;(base-rtl: -7) =&gt; tag38-direction
standard-problem-detail-entries standard-problem-detail-entries
custom-problem-detail-entries custom-problem-detail-entries
}> }&gt;
standard-problem-detail-entries = ( standard-problem-detail-entries = (
* nint => any * nint =&gt; any
) )
custom-problem-detail-entries = ( custom-problem-detail-entries = (
* (uint/~uri) => { + any =&gt; any } * (uint/~uri) => { + any =&gt; any }
) )
non-empty<M> = (M) .and ({ + any =&gt; any }) non-empty<M&gt; = (M) .and ({ + any =&gt; any })
oltext = text / tag38 oltext = text / tag38
]]></sourcecode> </sourcecode>
</figure> </figure>
<t>(Examples of elaborated Concise Problem Details data items can <t indent="0" pn="section-2-3">(Examples of elaborated Concise Problem Det
be found later in the document, e.g., <xref target="fig-example-custom-with-uri" ails data items can
/>.)</t> be found later in the document, e.g., <xref target="fig-example-custom-with-uri"
<t>A number of problem detail entries, the Standard Problem Detail format="default" sectionFormat="of" derivedContent="Figure 3"/>.)</t>
<t indent="0" pn="section-2-4">A number of problem detail entries, the Sta
ndard Problem Detail
entries, are predefined (more predefined details can be registered, entries, are predefined (more predefined details can be registered,
see <xref target="new-spdk"/>).</t> see <xref target="new-spdk" format="default" sectionFormat="of" derivedContent="
<t>Note that, unlike <xref target="RFC7807"/>, Concise Problem Details dat Section 3.1"/>).</t>
a items have <t indent="0" pn="section-2-5">Note that, unlike <xref target="RFC7807" fo
rmat="default" sectionFormat="of" derivedContent="RFC7807"/>, Concise Problem De
tails data items have
no explicit "problem type". no explicit "problem type".
Instead, the category (or, one could say, Gestalt) of the problem can 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 be understood from the shape of the problem details offered. We talk of
a "problem shape" for short.</t> a "problem shape" for short.</t>
<dl newline="true"> <dl newline="true" indent="3" spacing="normal" pn="section-2-6">
<dt>The title (key -1):</dt> <dt pn="section-2-6.1">The title (key -1):</dt>
<dd> <dd pn="section-2-6.2">
<t>A short, human-readable summary of the problem shape. <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 Beyond the shape of the problem, it is not intended to summarize all
the specific information given with the problem details. the specific information given with the problem details.
For instance, the summary might include that an account does not For instance, the summary might include that an account does not
have enough money for a transaction to succeed, but not the detail have enough money for a transaction to succeed but not the detailed
information such as the account number, how much money that account information such as the account number, how much money that account
has, and how much would be needed.</t> has, and how much would be needed.</t>
</dd> </dd>
<dt>The detail (key -2):</dt> <dt pn="section-2-6.3">The detail (key -2):</dt>
<dd> <dd pn="section-2-6.4">
<t>A human-readable explanation specific to this occurrence of the pro <t indent="0" pn="section-2-6.4.1">A human-readable explanation specif
blem.</t> ic to this occurrence of the problem.</t>
</dd> </dd>
<dt>The instance (key -3):</dt> <dt pn="section-2-6.5">The instance (key -3):</dt>
<dd> <dd pn="section-2-6.6">
<t>A URI reference that identifies the specific occurrence of the prob <t indent="0" pn="section-2-6.6.1">A URI reference that identifies the
lem. specific occurrence of the problem.
It may or may not yield further information if dereferenced.</t> It may or may not yield further information if dereferenced.</t>
</dd> </dd>
<dt>The response-code (key -4):</dt> <dt pn="section-2-6.7">The response-code (key -4):</dt>
<dd> <dd pn="section-2-6.8">
<t>The CoAP response code (Sections <xref target="RFC7252" section="5. <t indent="0" pn="section-2-6.8.1">The CoAP response code (Sections <x
9" sectionFormat="bare"/> and <xref target="RFC7252" section="12.1.2" sectionFor ref target="RFC7252" section="5.9" sectionFormat="bare" format="default" derived
mat="bare"/> of <xref target="RFC7252"/>) generated by the origin Link="https://rfc-editor.org/rfc/rfc7252#section-5.9" derivedContent="RFC7252"/>
and <xref target="RFC7252" section="12.1.2" sectionFormat="bare" format="defaul
t" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-12.1.2" derivedConten
t="RFC7252"/> of <xref target="RFC7252" format="default" sectionFormat="of" deri
vedContent="RFC7252"/>) generated by the origin
server for this occurrence of the problem.</t> server for this occurrence of the problem.</t>
</dd> </dd>
<dt>The base-uri (key -5):</dt> <dt pn="section-2-6.9">The base-uri (key -5):</dt>
<dd> <dd pn="section-2-6.10">
<t>The base URI (<xref section="5.1" sectionFormat="of" target="STD66" <t indent="0" pn="section-2-6.10.1">The base URI (see Section <xref se
/>) that should be used to resolve ction="5.1" sectionFormat="bare" target="RFC3986" format="default" derivedLink="
https://rfc-editor.org/rfc/rfc3986#section-5.1" derivedContent="RFC3986"/> of RF
C 3986 <xref target="STD66" format="default" sectionFormat="of" derivedContent="
STD66"/>) that should be used to resolve
relative URI references embedded in this Concise Problem Details relative URI references embedded in this Concise Problem Details
data item.</t> data item.</t>
</dd> </dd>
<dt>The base-lang (key -6):</dt> <dt pn="section-2-6.11">The base-lang (key -6):</dt>
<dd> <dd pn="section-2-6.12">
<t>The language-tag (tag38-ltag) that applies to the presentation of <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 unadorned text strings (not using tag 38) in this Concise Problem
Details data item, see <xref target="tag38"/>.</t> Details data item; see <xref target="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
</dd> </dd>
<dt>The base-rtl (key -7):</dt> <dt pn="section-2-6.13">The base-rtl (key -7):</dt>
<dd> <dd pn="section-2-6.14">
<t>The writing-direction (tag38-direction) that applies to the <t indent="0" pn="section-2-6.14.1">The writing-direction (tag38-direc
tion) that applies to the
presentation of unadorned text strings (not using tag 38) in this presentation of unadorned text strings (not using tag 38) in this
Concise Problem Details data item, see <xref target="tag38"/>.</t> Concise Problem Details data item; see <xref target="tag38" format="default" sec tionFormat="of" derivedContent="Appendix A"/>.</t>
</dd> </dd>
</dl> </dl>
<t>Both "title" and "detail" can use either an unadorned CBOR text string <t indent="0" pn="section-2-7">Both "title" and "detail" can use either an
(<tt>text</tt>) or a language-tagged text string (<tt>tag38</tt>); see <xref tar unadorned CBOR text string
get="tag38"/> for (<tt>text</tt>) or a language-tagged text string (<tt>tag38</tt>); see <xref tar
get="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/> fo
r
the definition of the latter. the definition of the latter.
Language tag and writing direction information for unadorned text Language tag and writing direction information for unadorned text
strings are intended to be obtained from context; if that context strings is intended to be obtained from context; if that context
needs to be saved or forwarded with a Concise Problem Details data needs to be saved or forwarded with a Concise Problem Details data
item, "base-lang" and "base-rtl" can be used for that. item, "base-lang" and "base-rtl" can be used.
If no such (explicitly saved or implicit) context information is If no such (explicitly saved or implicit) context information is
available, unadorned text is interpreted with language-tag "en" and available, unadorned text is interpreted with language-tag "en" and
writing-direction "false" (ltr).</t> writing-direction "false" (ltr).</t>
<t>The "title" string is advisory and included to give <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> consumers a shorthand for the category (problem shape) of the error encountered. </t>
<t>The "detail" member, if present, ought to focus on helping the client <t indent="0" pn="section-2-9">The "detail" member, if present, ought to f
correct the problem, rather than giving extensive server-side ocus on helping the client
correct the problem rather than giving extensive server-side
debugging information. debugging information.
Consumers <bcp14>SHOULD NOT</bcp14> parse the "detail" member for information; Consumers <bcp14>SHOULD NOT</bcp14> parse the "detail" member for information;
extensions (see <xref target="sec-new-attributes"/>) are more suitable and less extensions (see <xref target="sec-new-attributes" format="default" sectionFormat ="of" derivedContent="Section 3"/>) are more suitable and less
error-prone ways to obtain such information. error-prone ways to obtain such information.
Note that the "instance" URI reference may be relative; this means Note that the "instance" URI reference may be relative; this means
that it must be resolved relative to the representation's base URI, as that it must be resolved relative to the representation's base URI, as
per <xref section="5" sectionFormat="of" target="STD66"/>.</t> per Section <xref section="5" sectionFormat="bare" target="RFC3986" format="defa
<t>The "response-code" member, if present, is only advisory; it conveys ult" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-5" derivedContent="
RFC3986"/> of RFC 3986 <xref target="STD66" format="default" sectionFormat="of"
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. 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 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 response; the latter is needed to assure that generic CoAP software that
does not understand the problem-details format still behaves does not understand the problem-details format still behaves
correctly. correctly.
Consumers can use the response-code member to determine what the Consumers can use the "response-code" member to determine what the
original response code used by the generator was, in cases where it 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 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 bodies persist without CoAP information (e.g., in an events log or analytics
database). database).
Generic CoAP software will still use the CoAP response code. Generic CoAP software will still use the CoAP response code.
To support the use case of message body persistence without support by To support the use case of message-body persistence without support by
the problem-details generator, the entity that persists the Concise the problem-details generator, the entity that persists the Concise
Problem Details data item can copy over the CoAP response code Problem Details data item can copy over the CoAP response code
that it received on the CoAP level. that it received on the CoAP level.
Note that the "response-code" value is a numeric representation of the Note that the "response-code" value is a numeric representation of the
actual code (see <xref section="3" sectionFormat="of" target="RFC7252"/>), so it does not take the usual actual code (see <xref section="3" sectionFormat="of" target="RFC7252" format="d efault" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-3" derivedConten t="RFC7252"/>), so it does not take the usual
presentation form that resembles an presentation form that resembles an
HTTP status code -- <tt>4.04 Not found</tt> is represented by the number 132.</t HTTP status code: <tt>4.04 Not Found</tt> is represented by the number 132.</t>
> <t indent="0" pn="section-2-11">The "base-uri" member is usually not prese
<t>The "base-uri" member is usually not present in the initial nt in the initial
request-response communication as it can be inferred as per <xref section="5.1.3 request-response communication as it can be inferred as per Section <xref sectio
" sectionFormat="of" target="STD66"/>. n="5.1.3" sectionFormat="bare" target="RFC3986" format="default" derivedLink="ht
tps://rfc-editor.org/rfc/rfc3986#section-5.1.3" derivedContent="RFC3986"/> of RF
C 3986 <xref target="STD66" format="default" sectionFormat="of" derivedContent="
STD66"/>.
An entity that stores a Concise Problem Details data item or otherwise An entity that stores a Concise Problem Details data item or otherwise
makes it available for consumers without this context might add in a makes it available for consumers without this context might add in a
base-uri member to allow those consumers to perform resolution of any "base-uri" member to allow those consumers to perform resolution of any
relative URI references embedded in the data item.</t> relative URI references embedded in the data item.</t>
</section> </section>
<section anchor="sec-new-attributes"> <section anchor="sec-new-attributes" numbered="true" removeInRFC="false" toc
<name>Extending Concise Problem Details</name> ="include" pn="section-3">
<t>This specification defines a generic problem details container with onl <name slugifiedName="name-extending-concise-problem-d">Extending Concise P
y a roblem Details</name>
<t indent="0" pn="section-3-1">This specification defines a generic proble
m-details container with only a
minimal set of attributes to make it usable.</t> minimal set of attributes to make it usable.</t>
<t>It is expected that applications will extend the base format by definin g new <t indent="0" pn="section-3-2">It is expected that applications will exten d the base format by defining new
attributes.</t> attributes.</t>
<t>These new attributes fall into two categories: generic and application <t indent="0" pn="section-3-3">These new attributes fall into two categori es: generic and application
specific.</t> specific.</t>
<t>Generic attributes will be allocated in the <tt>standard-problem-detail <t indent="0" pn="section-3-4">Generic attributes will be allocated in the
-entries</tt> <tt>standard-problem-detail-entries</tt>
slot according to the registration procedure defined in <xref target="new-spdk"/ slot according to the registration procedure defined in <xref target="new-spdk"
>.</t> format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</t>
<t>Application-specific attributes will be allocated in the <t indent="0" pn="section-3-5">Application-specific attributes will be all
ocated in the
<tt>custom-problem-detail-entries</tt> slot according to the procedure described in <tt>custom-problem-detail-entries</tt> slot according to the procedure described in
<xref target="new-cpdk"/>.</t> <xref target="new-cpdk" format="default" sectionFormat="of" derivedContent="Sect
<t anchor="ignore-unknown">Consumers of a Concise Problem Details data ite ion 3.2"/>.</t>
m <bcp14>MUST</bcp14> ignore any <t anchor="ignore-unknown" indent="0" pn="section-3-6">Consumers of a Conc
Standard or Custom Problem Detail entries, or keys inside the Custom ise 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 Problem Detail entries, that they do not recognize ("ignore-unknown
rule"); this allows problem details to evolve. rule"); this allows problem details to evolve. When storing the data item for f
When storing the data item for future use or forwarding it to other uture use or forwarding it to other
consumers, it is strongly <bcp14>RECOMMENDED</bcp14> to retain the unrecognized consumers, it is strongly <bcp14>RECOMMENDED</bcp14> to retain the unrecognized
entries; exceptions might be when storage/forwarding occurs in a entries; exceptions might be when storage or forwarding occurs in a
different format/protocol that cannot accommodate them, or when the different format/protocol that cannot accommodate them or when the
storage/forwarding function needs to filter out privacy-sensitive storage or forwarding function needs to filter out privacy-sensitive
information and for that needs to assume unrecognized entries might be information and for that needs to assume unrecognized entries might be
privacy-sensitive.</t> privacy-sensitive.</t>
<section anchor="new-spdk"> <section anchor="new-spdk" numbered="true" removeInRFC="false" toc="includ
<name>Standard Problem Detail Entries</name> e" pn="section-3.1">
<t>Beyond the Standard Problem Detail keys defined in <xref target="cddl <name slugifiedName="name-standard-problem-detail-ent">Standard Problem
"/>, additional Detail Entries</name>
<t indent="0" pn="section-3.1-1">Beyond the Standard Problem Detail keys
defined in <xref target="cddl" format="default" sectionFormat="of" derivedConte
nt="Figure 2"/>, additional
Standard Problem Detail keys can be registered for use in the Standard Problem Detail keys can be registered for use in the
<tt>standard-problem-detail-entries</tt> slot (see <xref target="iana-spdk"/>).< <tt>standard-problem-detail-entries</tt> slot (see <xref target="iana-spdk" form
/t> at="default" sectionFormat="of" derivedContent="Section 6.1"/>).</t>
<t>Standard Problem Detail keys are negative integers, so they can never <t indent="0" pn="section-3.1-2">Standard Problem Detail keys are negati
ve integers, so they can never
conflict with Custom Problem Detail keys defined for a specific conflict with Custom Problem Detail keys defined for a specific
application domain application domain
(which are unsigned integers or URIs.)</t> (which are unsigned integers or URIs.)</t>
<t>In summary, the keys for Standard Problem Detail entries are in a <t indent="0" pn="section-3.1-3">In summary, the keys for Standard Probl em Detail entries are in a
global namespace that is not specific to a particular application domain.</t> global namespace that is not specific to a particular application domain.</t>
<section anchor="uco"> <section anchor="uco" numbered="true" removeInRFC="false" toc="include"
<name>Standard Problem Detail Entry: Unprocessed CoAP Option</name> pn="section-3.1.1">
<t><xref target="basic"/> provides a number of generally applicable St <name slugifiedName="name-standard-problem-detail-entr">Standard Probl
andard Problem em Detail Entry: Unprocessed CoAP Option</name>
Detail Entries. The present section both registers another useful <t indent="0" pn="section-3.1.1-1"><xref target="basic" format="defaul
t" sectionFormat="of" derivedContent="Section 2"/> provides a number of generall
y applicable Standard Problem
Detail entries. The present section both registers another useful
Standard Problem Detail entry and serves as an example of a Standard Standard Problem Detail entry and serves as an example of a Standard
Problem Detail Entry registration, in the registration template format Problem Detail Entry registration, in the registration template format
that would be ready for registration.</t> that would be ready for registration.</t>
<blockquote> <dl newline="true" spacing="compact" indent="3" pn="section-3.1.1-2">
<dl> <dt pn="section-3.1.1-2.1">Key value:</dt>
<dt>Key Value:</dt> <dd pn="section-3.1.1-2.2">
<dd> <t indent="0" pn="section-3.1.1-2.2.1">-8</t>
<t>TBD (assigned at registration)</t> </dd>
</dd> <dt pn="section-3.1.1-2.3">Name:</dt>
<dt>Name:</dt> <dd pn="section-3.1.1-2.4">
<dd> <t indent="0" pn="section-3.1.1-2.4.1">unprocessed-coap-option</t>
<t>unprocessed-coap-option</t> </dd>
</dd> <dt pn="section-3.1.1-2.5">CDDL type:</dt>
<dt>CDDL type:</dt> <dd pn="section-3.1.1-2.6">
<dd> <t indent="0" pn="section-3.1.1-2.6.1"><tt>one-or-more&lt;uint&gt;
<t><tt>one-or-more&lt;uint&gt;</tt>, where </tt>, where
</t> </t>
<artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-3.1.1-2.6.2">
one-or-more<T> = T / [ 2* T ] one-or-more&lt;T&gt; = T / [ 2* T ]
]]></artwork> </sourcecode>
</dd> </dd>
<dt>Brief description:</dt> <dt pn="section-3.1.1-2.7">Brief description:</dt>
<dd> <dd pn="section-3.1.1-2.8">
<t>Option number(s) of CoAP option(s) that were not understood</ <t indent="0" pn="section-3.1.1-2.8.1">Option number(s) of CoAP op
t> tion(s) that were not understood</t>
</dd> </dd>
<dt>Specification reference:</dt> <dt pn="section-3.1.1-2.9">Specification reference:</dt>
<dd> <dd pn="section-3.1.1-2.10">
<t><xref target="uco"/> of RFC XXXX</t> <t indent="0" pn="section-3.1.1-2.10.1"><xref target="uco" format=
</dd> "default" sectionFormat="of" derivedContent="Section 3.1.1"/> of RFC 9290</t>
</dl> </dd>
</blockquote> </dl>
<t><cref anchor="to-be-removed">RFC Editor: please replace RFC XXXX wi <t indent="0" pn="section-3.1.1-3">The specification of the Standard P
th the RFC roblem Detail entry referenced by
number of this RFC and remove this note.</cref></t>
<t>The specification of the Standard Problem Detail entry referenced b
y
the above registration template follows:</t> the above registration template follows:</t>
<t>The Standard Problem Detail entry <tt>unprocessed-coap-option</tt> <t indent="0" pn="section-3.1.1-4">The Standard Problem Detail entry <
provides tt>unprocessed-coap-option</tt> provides
the option number(s) of CoAP option(s) present in the request that the option number or numbers of any CoAP options present in the request that
could not be processed by the server.</t> could not be processed by the server.</t>
<t>This may be a critical option that the server is unaware of, or an <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 option the server is aware of but could not process (and chose not
to, or was not allowed to, ignore it).</t> to, or was not allowed to, ignore it).</t>
<t>The Concise Problem Details data item including this Standard <t indent="0" pn="section-3.1.1-6">The Concise Problem Details data it em including this Standard
Problem Detail Entry can be used in fulfillment of the "<bcp14>SHOULD</bcp14>" 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> requirement in <xref section="5.4.1" sectionFormat="of" target="RFC7252" format=
<t>Several option numbers may be given in a list (in no particular ord "default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.4.1" derived
er), Content="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 without any guarantee that the list is a complete representation of
all the problems in the request (as the server might all the problems in the request (as the server might
have stopped processing already at one of the problematic options). have stopped processing already at one of the problematic options).
If an option with the given number was repeated, there is no If an option with the given number was repeated, there is no
indication which of the values caused the error.</t> indication which of the values caused the error.</t>
<t>Clients need to expect seeing options in the list they did not send <t indent="0" pn="section-3.1.1-8">Clients need to expect to see optio ns in the list that they did not send
in the request; this can happen if the request traversed a proxy in the request; this can happen if the request traversed a proxy
that added the option but did not act on the problem details that added the option but did not act on the problem-details
response being returned by the origin server.</t> response being returned by the origin server.</t>
<t>Note that for a few special values of unprocessed CoAP <t indent="0" pn="section-3.1.1-9">For a few special values of unproce
options (such as Accept or Proxy-Uri), there are special response ssed CoAP
options (such as Accept or Proxy-Uri), note that there are special response
codes (4.06 Not Acceptable, 5.05 Proxying Not Supported, codes (4.06 Not Acceptable, 5.05 Proxying Not Supported,
respectively) to be sent instead of 4.02 Bad Option.</t> respectively) to be sent instead of 4.02 Bad Option.</t>
</section> </section>
</section> </section>
<section anchor="new-cpdk"> <section anchor="new-cpdk" numbered="true" removeInRFC="false" toc="includ
<name>Custom Problem Detail Entries</name> e" pn="section-3.2">
<t>Applications may extend the Problem Details data item with <name slugifiedName="name-custom-problem-detail-entri">Custom Problem De
tail Entries</name>
<t indent="0" pn="section-3.2-1">Applications may extend the Concise Pro
blem Details data item with
additional entries to convey additional, application-specific information.</t> additional entries to convey additional, application-specific information.</t>
<t>Such new entries are allocated in the <tt>custom-problem-detail-entri <t indent="0" pn="section-3.2-2">Such new entries are allocated in the <
es</tt> slot, and tt>custom-problem-detail-entries</tt> slot and
carry a nested map specific to that application. The map key can either be carry a nested map specific to that application. The map key can be either
an (absolute!) URI (under control of the entity defining this extension), an (absolute!) URI (under control of the entity defining this extension)
or an unsigned integer. or an unsigned integer.
Only the latter needs to be registered (<xref target="iana-cpdk"/>).</t> Only the latter needs to be registered (<xref target="iana-cpdk" format="default
<t>Within the nested map, any number of attributes can be given for a " sectionFormat="of" derivedContent="Section 6.2"/>).</t>
<t indent="0" pn="section-3.2-3">Within the nested map, any number of at
tributes can be given for a
single extension. single extension.
The semantics of each custom attribute <bcp14>MUST</bcp14> be described in the The semantics of each custom attribute <bcp14>MUST</bcp14> be described in the
documentation for the extension; for extensions that are registered documentation for the extension; for extensions that are registered
(i.e., are identified by an unsigned int) that documentation goes (i.e., are identified by an unsigned int), that documentation goes
along with the registration.</t> along with the registration.</t>
<t>The unsigned integer form allows a more compact representation. <t indent="0" pn="section-3.2-4">The unsigned integer form allows a more compact representation.
In In
exchange, authors are expected to comply with the required exchange, authors are expected to comply with the required
registration and documentation process. registration and documentation process.
In comparison, the URI form is less space-efficient but requires no In comparison, the URI form is less space efficient but requires no
registration. It is therefore useful for experimenting during the development registration. Therefore, it is useful for experimenting during the development
cycle and for applications deployed in environments where producers and cycle and for applications deployed in environments where producers and
consumers of Concise Problem Details are more tightly integrated. consumers of Concise Problem Details are more tightly integrated.
(The URI form thus covers the potential need we might otherwise have for a "priv (Thus, the URI form covers the potential need we might otherwise have for a "Pri
ate use" range for the unsigned integers.)</t> vate Use" range for the unsigned integers.)</t>
<t anchor="no-dereference">Note that the URI given for the extension is <t anchor="no-dereference" indent="0" pn="section-3.2-5">Note that the U
for identification RI given for the extension is for identification
purposes only and, even if dereferenceable in principle, it <bcp14>MUST NOT</bcp 14> be purposes only and, even if dereferenceable in principle, it <bcp14>MUST NOT</bcp 14> be
dereferenced in the normal course of handling problem details (i.e., outside dereferenced in the normal course of handling problem details (i.e., outside
diagnostic/debugging procedures involving humans).</t> diagnostic or debugging procedures involving humans).</t>
<t><xref target="fig-example-custom-with-uri"/> shows an example (in CBO <t indent="0" pn="section-3.2-6"><xref target="fig-example-custom-with-u
R diagnostic notation) ri" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an exa
of a custom extension using a (made-up) URI as <tt>custom-problem-detail-entries mple (in CBOR diagnostic notation)
</tt> key.</t> of a custom extension using a (made-up) URI as the <tt>custom-problem-detail-ent
<figure anchor="fig-example-custom-with-uri"> ries</tt> key.</t>
<name>Example Extension with URI key</name> <figure anchor="fig-example-custom-with-uri" align="left" suppress-title
<artwork type="cbor-diag" align="center"><![CDATA[ ="false" pn="figure-3">
<name slugifiedName="name-example-extension-with-uri-">Example Extensi
on with URI Key</name>
<sourcecode type="cbor-diag" markers="false" pn="section-3.2-7.1">
{ {
/ title / -1: "title of the error", / title / -1: "title of the error",
/ detail / -2: "detailed information about the error", / detail / -2: "detailed information about the error",
/ instance / -3: "coaps://pd.example/FA317434", / instance / -3: "coaps://pd.example/FA317434",
/ response-code / -4: 128, / 4.00 / / response-code / -4: 128, / 4.00 /
"tag:3gpp.org,2022-03:TS29112": { "tag:3gpp.org,2022-03:TS29112": {
/ cause / 0: "machine-readable error cause", / cause / 0: "machine-readable error cause",
/ invalidParams / 1: [ / invalidParams / 1: [
[ [
/ param / "first parameter name", / param / "first parameter name",
/ reason / "must be a positive integer" / reason / "must be a positive integer"
], ],
[ [
/ param / "second parameter name" / param / "second parameter name"
] ]
], ],
/ supportedFeatures / 2: "d34db33f" / supportedFeatures / 2: "d34db33f"
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<t>Obviously, an SDO like 3GPP can also easily register such a custom <t indent="0" pn="section-3.2-8">Obviously, a Standards Development Orga
problem detail entry to receive a more efficient unsigned integer key; nization (SDO) like 3GPP can also easily register such a Custom
<xref target="fig-example-custom-with-uint"/> shows how Problem Detail entry to receive a more efficient unsigned integer key;
the same example would look like using a (made-up) registered unsigned int as <xref target="fig-example-custom-with-uint" format="default" sectionFormat="of"
derivedContent="Figure 4"/> shows how
the same example would look using a (made-up) registered unsigned int as the
<tt>custom-problem-detail-entries</tt> key:</t> <tt>custom-problem-detail-entries</tt> key:</t>
<figure anchor="fig-example-custom-with-uint"> <figure anchor="fig-example-custom-with-uint" align="left" suppress-titl
<name>Example Extension with unsigned int (registered) key</name> e="false" pn="figure-4">
<artwork type="cbor-diag" align="center"><![CDATA[ <name slugifiedName="name-example-extension-with-unsi">Example Extensi
on with Unsigned Int (Registered) Key</name>
<sourcecode type="cbor-diag" markers="false" pn="section-3.2-9.1">
{ {
/ title / -1: "title of the error", / title / -1: "title of the error",
/ detail / -2: "detailed information about the error", / detail / -2: "detailed information about the error",
/ instance / -3: "coaps://pd.example/FA317434", / instance / -3: "coaps://pd.example/FA317434",
/ response-code / -4: 128, / 4.00 / / response-code / -4: 128, / 4.00 /
/4711 is made-up example key that is not actually registered:/ /4711 is made-up example key that is not actually registered:/
4711: { 4711: {
/ cause / 0: "machine-readable error cause", / cause / 0: "machine-readable error cause",
/ invalidParams / 1: [ / invalidParams / 1: [
skipping to change at line 470 skipping to change at line 583
/ param / "first parameter name", / param / "first parameter name",
/ reason / "must be a positive integer" / reason / "must be a positive integer"
], ],
[ [
/ param / "second parameter name" / param / "second parameter name"
] ]
], ],
/ supportedFeatures / 2: "d34db33f" / supportedFeatures / 2: "d34db33f"
} }
} }
]]></artwork> </sourcecode>
</figure> </figure>
<t>In summary, the keys for the maps used inside Custom Problem Detail <t indent="0" pn="section-3.2-10">In summary, the keys for the maps used
entries are defined specifically to the identifier of that Custom Problem Detail inside Custom Problem Detail
entry, the documentation of which defines these internal entries, entries are defined specifically for use with the identifier of that Custom
typically chosen to address a given application domain.</t> Problem Detail entry, the documentation of which defines these
<t>When there is a need to evolve a Custom Problem Detail entry definiti internal entries, typically chosen to address a given application
on, the domain.</t>
"ignore-unknown rule" discussed in the introduction to <t indent="0" pn="section-3.2-11">When there is a need to evolve a Custo
<xref target="sec-new-attributes"/> provides an easy way to include additional i m Problem Detail entry definition, the
nformation. "ignore-unknown rule" discussed in <xref target="sec-new-attributes" format="def
The assumption is that this is done in a backward and forward ault" sectionFormat="of" derivedContent="Section 3"/> provides an easy way to in
compatible way. clude additional information.
The assumption is that this is done in a backward- and forward-compatible way.
Sometimes, Custom Problem Detail entries may need to evolve in a way where Sometimes, Custom Problem Detail entries may need to evolve in a way where
forward compatibility by applying the "ignore-unknown rule" would not forward compatibility by applying the "ignore-unknown rule" would not
be appropriate: e.g., when adding a "must-understand" member, be appropriate: for example, when adding a "must-understand" member,
which can only which can only
be ignored at the peril of misunderstanding the Concise Problem be ignored at the peril of misunderstanding the Concise Problem
Details data item ("false interoperability"). Details data item ("false interoperability").
In this case, a new Custom Problem Detail key can simply be In this case, a new Custom Problem Detail key can simply be
registered for this case, keeping the old key backward and registered for this case, keeping the old key backward and
forward compatible.</t> forward compatible.</t>
</section> </section>
</section> </section>
<section anchor="privcons"> <section anchor="privcons" numbered="true" removeInRFC="false" toc="include"
<name>Privacy Considerations</name> pn="section-4">
<t>Problem details may unintentionally disclose information. <name slugifiedName="name-privacy-considerations">Privacy Considerations</
name>
<t indent="0" pn="section-4-1">Problem details may unintentionally disclos
e information.
This can lead to both privacy and security problems. This can lead to both privacy and security problems.
See <xref target="seccons"/> for more details that apply to both domains; partic ular See <xref target="seccons" format="default" sectionFormat="of" derivedContent="S ection 5"/> for more details that apply to both domains; particular
attention needs to be given to unintentionally disclosing Personally attention needs to be given to unintentionally disclosing Personally
Identifiable Information (PII).</t> Identifiable Information (PII).</t>
</section> </section>
<section anchor="seccons"> <section anchor="seccons" numbered="true" removeInRFC="false" toc="include"
<name>Security Considerations</name> pn="section-5">
<t>Concise Problem Details can contain URIs that are not intended to be <name slugifiedName="name-security-considerations">Security Considerations
dereferenced (<xref target="no-dereference"/>). One reason is that dereferencin </name>
g <t indent="0" pn="section-5-1">Concise Problem Details can contain URIs th
at are not intended to be
dereferenced (<xref 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). these can lead to information disclosure (tracking).
Information disclosure can also be caused by URIs in problem details Information disclosure can also be caused by URIs in problem details
that <em>are</em> intended for dereferencing, e.g., the "instance" URI. that <em>are</em> intended for dereferencing, e.g., the "instance" URI.
Implementations need to consider which component of a client should Implementations need to consider which component of a client should
perform the dereferencing, and which servers are trusted with serving perform the dereferencing and which servers are trusted with serving
them. them.
In any case, the security considerations of <xref section="7" sectionFormat="of" In any case, the security considerations of Section <xref section="7" sectionFor
target="STD66"/> apply.</t> mat="bare" target="RFC3986" format="default" derivedLink="https://rfc-editor.org
<t>The security and privacy considerations outlined in <xref section="5" s /rfc/rfc3986#section-7" derivedContent="RFC3986"/> of RFC 3986 <xref target="STD
ectionFormat="of" target="RFC7807"/> apply in full. 66" format="default" sectionFormat="of" derivedContent="STD66"/> apply.</t>
While these are phrased in terms of security considerations for new <t indent="0" pn="section-5-2">The security and privacy considerations out
RFC 7807 problem types, they equally apply to the problem detail lined in <xref section="5" sectionFormat="of" target="RFC7807" format="default"
entry definitions used here <xref target="sec-new-attributes"/>; in summary: bot derivedLink="https://rfc-editor.org/rfc/rfc7807#section-5" derivedContent="RFC78
h 07"/> apply in full.
when defining new detail entries, and when actually generating a
While these are phrased in terms of security considerations for new RFC 7807 pro
blem types, they equally apply to the problem detail
entry definitions used here (<xref target="sec-new-attributes" format="default"
sectionFormat="of" derivedContent="Section 3"/>). In summary, both
when defining new detail entries and when actually using them to generate a
Concise Problem Details data item, care needs to be taken that they do Concise Problem Details data item, care needs to be taken that they do
not leak sensitive information. not leak sensitive information.
Entities storing or forwarding Concise Problem Details data items need Entities storing or forwarding Concise Problem Details data items need
to consider whether this leads to information being transferred out of to consider whether this leads to information being transferred out of
the context within which access to sensitive information was acceptable. the context within which access to sensitive information was acceptable.
See also <xref target="ignore-unknown"/> (the last paragraph of the introduction to See also <xref target="ignore-unknown" format="default" sectionFormat="of" deriv edContent="Section 3, Paragraph 6"/> (the last paragraph of the introduction to
that section). that section).
Privacy-sensitive information in the problem details <bcp14>SHOULD Privacy-sensitive information in the problem details <bcp14>SHOULD NOT</bcp14> b
NOT</bcp14> be obscured in ways that might lead to misclassification as e obscured in ways that might lead to misclassification as
non-sensitive (e.g., by base64-encoding).</t> non-sensitive (e.g., by base64-encoding).</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<name>IANA Considerations</name> c="include" pn="section-6">
<t><cref anchor="to-be-removed_1">RFC Editor: please replace RFC XXXX with <name slugifiedName="name-iana-considerations">IANA Considerations</name>
the RFC <section anchor="iana-spdk" numbered="true" removeInRFC="false" toc="inclu
number of this RFC and remove this note.</cref></t> de" pn="section-6.1">
<section anchor="iana-spdk"> <name slugifiedName="name-standard-problem-detail-key">Standard Problem
<name>Standard Problem Detail Key registry</name> Detail Keys Registry</name>
<!-- {{content-formats (CoAP Content-Formats)<IANA.core-parameters}} --> <t indent="0" pn="section-6.1-1">This specification defines a new subreg
istry titled "Standard Problem
<t>This specification defines a new sub-registry for Standard Problem Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registr
Detail Keys in the CoRE Parameters registry <xref target="IANA.core-parameters"/ y <xref target="IANA.core-parameters" format="default" sectionFormat="of" derive
>, dContent="IANA.core-parameters"/>,
with the policy "specification required" (<xref section="4.6" sectionFormat="of" with "Specification Required" as the Registration Procedure (<xref section="4.6"
target="RFC8126"/>).</t> sectionFormat="of" target="RFC8126" format="default" derivedLink="https://rfc-e
<t>Each entry in the registry must include:</t> ditor.org/rfc/rfc8126#section-4.6" derivedContent="RFC8126"/>).</t>
<dl newline="true"> <t indent="0" pn="section-6.1-2">Each entry in the registry must include
<dt>Key value:</dt> :</t>
<dd> <dl newline="true" indent="3" spacing="normal" pn="section-6.1-3">
<t>a negative integer to be used as the value of the key</t> <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 a
s the value of the key</t>
</dd> </dd>
<dt>Name:</dt> <dt pn="section-6.1-3.3">Name:</dt>
<dd> <dd pn="section-6.1-3.4">
<t>a name that could be used in implementations for the key</t> <t indent="0" pn="section-6.1-3.4.1">a name that could be used in im
plementations for the key</t>
</dd> </dd>
<dt>CDDL type:</dt> <dt pn="section-6.1-3.5">CDDL Type:</dt>
<dd> <dd pn="section-6.1-3.6">
<t>type of the data associated with the key in CDDL notation</t> <t indent="0" pn="section-6.1-3.6.1">type of the data associated wit
h the key in CDDL notation</t>
</dd> </dd>
<dt>Brief description:</dt> <dt pn="section-6.1-3.7">Brief Description:</dt>
<dd> <dd pn="section-6.1-3.8">
<t>a brief description</t> <t indent="0" pn="section-6.1-3.8.1">a brief description</t>
</dd> </dd>
<dt>Change Controller:</dt> <dt pn="section-6.1-3.9">Reference:</dt>
<dd> <dd pn="section-6.1-3.10">
<t>(see <xref section="2.3" sectionFormat="of" target="RFC8126"/>)</ <t indent="0" pn="section-6.1-3.10.1">a reference document</t>
t>
</dd> </dd>
<dt>Reference:</dt> <dt pn="section-6.1-3.11">Change Controller:</dt>
<dd> <dd pn="section-6.1-3.12">
<t>a reference document</t> <t indent="0" pn="section-6.1-3.12.1">(see <xref section="2.3" secti
onFormat="of" target="RFC8126" format="default" derivedLink="https://rfc-editor.
org/rfc/rfc8126#section-2.3" derivedContent="RFC8126"/>)</t>
</dd> </dd>
</dl> </dl>
<t>The expert is requested to assign the shortest key values (1+0 and <t indent="0" pn="section-6.1-4">The designated expert is requested to a ssign the shortest key values (1+0 and
1+1 encoding) to registrations that are likely to enjoy wide use and 1+1 encoding) to registrations that are likely to enjoy wide use and
can benefit from short encodings.</t> can benefit from short encodings.</t>
<t>To be immediately useful in CDDL and programming language contexts, a <t indent="0" pn="section-6.1-5">To be immediately useful in CDDL and pr
name consists of a lower-case ASCII letter (a-z) and zero or more ogramming-language contexts, a
additional ASCII characters that are either lower-case letters, name consists of a lowercase ASCII letter (a-z) and zero or more
additional ASCII characters that are either lowercase letters,
digits, or a hyphen-minus, i.e., it matches <tt>[a-z][-a-z0-9]*</tt>. 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> As with the key values, names need to be unique.</t>
<t>The specification in the reference document needs to provide a <t indent="0" pn="section-6.1-6">The specification in the reference docu ment needs to provide a
description of the Standard Problem Detail entry, replicating the CDDL description of the Standard Problem Detail entry, replicating the CDDL
description in "CDDL type", and describing the semantics of the description in "CDDL Type", and describing the semantics of the
presence of this entry and the semantics of the value given with it.</t> presence of this entry and the semantics of the value given with it.</t>
<t>Initial entries in this sub-registry are as follows:</t> <t indent="0" pn="section-6.1-7">Initial entries in this subregistry are
<table anchor="spdk"> as follows:</t>
<name>Initial Entries in the Standard Problem Detail Key registry</nam <table anchor="spdk" align="center" pn="table-1">
e> <name slugifiedName="name-initial-entries-in-the-stan">Initial Entries
in the Standard Problem Detail Keys Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key value</th> <th align="left" colspan="1" rowspan="1">Key Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">CDDL Type</th> <th align="left" colspan="1" rowspan="1">CDDL Type</th>
<th align="left">Brief description</th> <th align="left" colspan="1" rowspan="1">Brief Description</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
<th align="left" colspan="1" rowspan="1">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">-1</td> <td align="left" colspan="1" rowspan="1">-1</td>
<td align="left">title</td> <td align="left" colspan="1" rowspan="1">title</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>text / tag38</tt></td> <tt>text / tag38</tt></td>
<td align="left">short, human-readable summary of the problem shap <td align="left" colspan="1" rowspan="1">Short, human-readable sum
e</td> mary of the problem shape</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-2</td> <td align="left" colspan="1" rowspan="1">-2</td>
<td align="left">detail</td> <td align="left" colspan="1" rowspan="1">detail</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>text / tag38</tt></td> <tt>text / tag38</tt></td>
<td align="left">human-readable explanation specific to this occur <td align="left" colspan="1" rowspan="1">Human-readable explanatio
rence of the problem</td> n specific to this occurrence of the problem</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-3</td> <td align="left" colspan="1" rowspan="1">-3</td>
<td align="left">instance</td> <td align="left" colspan="1" rowspan="1">instance</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>~uri</tt></td> <tt>~uri</tt></td>
<td align="left">URI reference identifying specific occurrence of <td align="left" colspan="1" rowspan="1">URI reference identifying
the problem</td> specific occurrence of the problem</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-4</td> <td align="left" colspan="1" rowspan="1">-4</td>
<td align="left">response-code</td> <td align="left" colspan="1" rowspan="1">response-code</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>uint .size 1</tt></td> <tt>uint .size 1</tt></td>
<td align="left">CoAP response code</td> <td align="left" colspan="1" rowspan="1">CoAP response code</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-5</td> <td align="left" colspan="1" rowspan="1">-5</td>
<td align="left">base-uri</td> <td align="left" colspan="1" rowspan="1">base-uri</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>~uri</tt></td> <tt>~uri</tt></td>
<td align="left">Base URI</td> <td align="left" colspan="1" rowspan="1">Base URI</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-6</td> <td align="left" colspan="1" rowspan="1">-6</td>
<td align="left">base-lang</td> <td align="left" colspan="1" rowspan="1">base-lang</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>tag38-ltag</tt></td> <tt>tag38-ltag</tt></td>
<td align="left">Base language tag (see <xref target="tag38"/>)</t <td align="left" colspan="1" rowspan="1">Base language tag (see <x
d> ref target="tag38" format="default" sectionFormat="of" derivedContent="Appendix
<td align="left">RFC XXXX</td> A"/>)</td>
<td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">-7</td> <td align="left" colspan="1" rowspan="1">-7</td>
<td align="left">base-rtl</td> <td align="left" colspan="1" rowspan="1">base-rtl</td>
<td align="left"> <td align="left" colspan="1" rowspan="1">
<tt>tag38-direction</tt></td> <tt>tag38-direction</tt></td>
<td align="left">Base writing direction (see <xref target="tag38"/ <td align="left" colspan="1" rowspan="1">Base writing direction (s
>)</td> ee <xref target="tag38" format="default" sectionFormat="of" derivedContent="Appe
<td align="left">RFC XXXX</td> ndix A"/>)</td>
<td align="left" colspan="1" rowspan="1">RFC 9290</td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBD</td> <td align="left" colspan="1" rowspan="1">-8</td>
<td align="left">unprocessed-coap-option</td> <td align="left" colspan="1" rowspan="1">unprocessed-coap-option</
<td align="left"> td>
<td align="left" colspan="1" rowspan="1">
<tt>one-or-more&lt;uint&gt;</tt></td> <tt>one-or-more&lt;uint&gt;</tt></td>
<td align="left">Option number(s) of CoAP option(s) that were not <td align="left" colspan="1" rowspan="1">Option number(s) of CoAP
understood</td> option(s) that were not understood</td>
<td align="left">RFC XXXX, <xref target="uco"/></td> <td align="left" colspan="1" rowspan="1">RFC 9290, <xref target="u
co" format="default" sectionFormat="of" derivedContent="Section 3.1.1"/></td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="iana-cpdk"> <section anchor="iana-cpdk" numbered="true" removeInRFC="false" toc="inclu
<name>Custom Problem Detail Key registry</name> de" pn="section-6.2">
<t>This specification defines a new sub-registry for Custom Problem <name slugifiedName="name-custom-problem-detail-keys-">Custom Problem De
Detail Keys in the CoRE Parameters registry <xref target="IANA.core-parameters"/ tail Keys Registry</name>
>, <t indent="0" pn="section-6.2-1">This specification defines a new subreg
with the policy "expert review" (<xref section="4.5" sectionFormat="of" target=" istry titled "Custom Problem
RFC8126"/>).</t> Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registr
<t>The expert is instructed to attempt making the registration experienc y <xref target="IANA.core-parameters" format="default" sectionFormat="of" derive
e dContent="IANA.core-parameters"/>,
as close to first-come-first-served as reasonably achievable, but with as "Expert Review" as the Registration Procedure (<xref section="4.5
" sectionFormat="of" 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 as reasonably achievable, but
checking that the reference document does provide a description as set checking that the reference document does provide a description as set
out below. out below.
(This requirement is a relaxed version of "specification required" as (This requirement is a relaxed version of "Specification Required" as
defined in <xref section="4.6" sectionFormat="of" target="RFC8126"/>.)</t> defined in <xref section="4.6" sectionFormat="of" target="RFC8126" format="defau
<t>Each entry in the registry must include:</t> lt" derivedLink="https://rfc-editor.org/rfc/rfc8126#section-4.6" derivedContent=
<dl newline="true"> "RFC8126"/>.)</t>
<dt>Key value:</dt> <t indent="0" pn="section-6.2-3">Each entry in the registry must include
<dd> :</t>
<t>an unsigned integer to be used as the value of the key</t> <dl newline="true" indent="3" spacing="normal" pn="section-6.2-4">
</dd> <dt pn="section-6.2-4.1">Key Value:</dt>
<dt>Name:</dt> <dd pn="section-6.2-4.2">
<dd> <t indent="0" pn="section-6.2-4.2.1">an unsigned integer to be used
<t>a name that could be used in implementations for the key</t> as the value of the key</t>
</dd> </dd>
<dt>Brief description:</dt> <dt pn="section-6.2-4.3">Name:</dt>
<dd> <dd pn="section-6.2-4.4">
<t>a brief description</t> <t indent="0" pn="section-6.2-4.4.1">a name that could be used in im
plementations for the key</t>
</dd> </dd>
<dt>Change Controller:</dt> <dt pn="section-6.2-4.5">Brief Description:</dt>
<dd> <dd pn="section-6.2-4.6">
<t>(see <xref section="2.3" sectionFormat="of" target="RFC8126"/>)</ <t indent="0" pn="section-6.2-4.6.1">a brief description</t>
t>
</dd> </dd>
<dt>Reference:</dt> <dt pn="section-6.2-4.7">Reference:</dt>
<dd> <dd pn="section-6.2-4.8">
<t>a reference document that provides a description of the map, <t indent="0" pn="section-6.2-4.8.1">a reference document that provi
des a description of the map,
including a CDDL description, that describes all inside keys and including a CDDL description, that describes all inside keys and
values</t> values</t>
</dd> </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" secti
onFormat="of" target="RFC8126" format="default" derivedLink="https://rfc-editor.
org/rfc/rfc8126#section-2.3" derivedContent="RFC8126"/>)</t>
</dd>
</dl> </dl>
<t>The expert is requested to assign the shortest key values (1+0 and <t indent="0" pn="section-6.2-5">The designated expert is requested to a ssign the shortest key values (1+0 and
1+1 encoding) to registrations that are likely to enjoy wide use and 1+1 encoding) to registrations that are likely to enjoy wide use and
can benefit from short encodings.</t> can benefit from short encodings.</t>
<t>To be immediately useful in CDDL and programming language contexts, a <t indent="0" pn="section-6.2-6">To be immediately useful in CDDL and pr
name consists of a lower-case ASCII letter (a-z) and zero or more ogramming-language contexts, a
additional ASCII characters that are either lower-case letters, name consists of a lowercase ASCII letter (a-z) and zero or more
additional ASCII characters that are either lowercase letters,
digits, or a hyphen-minus, i.e., it matches <tt>[a-z][-a-z0-9]*</tt>. 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> As with the key values, names need to be unique.</t>
<t>Initial entries in this sub-registry are as follows:</t> <t indent="0" pn="section-6.2-7">Initial entries in this subregistry are
<table anchor="cpdk"> as follows:</t>
<name>Initial Entries in the Custom Problem Detail Key registry</name> <table 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>
<thead> <thead>
<tr> <tr>
<th align="left">Key value</th> <th align="left" colspan="1" rowspan="1">Key Value</th>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">Brief description</th> <th align="left" colspan="1" rowspan="1">Brief Description</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
<th align="left" colspan="1" rowspan="1">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">7807</td> <td align="left" colspan="1" rowspan="1">7807</td>
<td align="left">tunnel-7807</td> <td align="left" colspan="1" rowspan="1">tunnel-7807</td>
<td align="left">Carry RFC 7807 problem details in a Concise Probl <td align="left" colspan="1" rowspan="1">Carry RFC 7807 problem de
em Details data item</td> tails in a Concise Problem Details data item</td>
<td align="left">RFC XXXX, <xref target="comp7807"/></td> <td align="left" colspan="1" rowspan="1">RFC 9290, <xref target="c
omp7807" format="default" sectionFormat="of" derivedContent="Appendix B"/></td>
<td align="left" colspan="1" rowspan="1">IETF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="media-type"> <section anchor="media-type" numbered="true" removeInRFC="false" toc="incl
<name>Media Type</name> ude" pn="section-6.3">
<t>IANA is requested to add the following Media-Type to the "Media Types <name slugifiedName="name-media-type">Media Type</name>
" <t indent="0" pn="section-6.3-1">IANA has added the following media type
registry <xref target="IANA.media-types"/>.</t> to the "Media Types"
<table align="left" anchor="new-media-type"> registry <xref target="IANA.media-types" format="default" sectionFormat="of" der
<name>New Media Type application/concise-problem-details+cbor</name> ivedContent="IANA.media-types"/>.</t>
<table align="left" anchor="new-media-type" pn="table-3">
<name slugifiedName="name-new-media-type-application-">New Media Type
'application/concise-problem-details+cbor'</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left">Template</th> <th align="left" colspan="1" rowspan="1">Template</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">concise-problem-details+cbor</td> <td align="left" colspan="1" rowspan="1">concise-problem-details+c
<td align="left">application/concise-problem-details+cbor</td> bor</td>
<td align="left">RFC XXXX, <xref target="media-type"/></td> <td align="left" colspan="1" rowspan="1">application/concise-probl
em-details+cbor</td>
<td align="left" colspan="1" rowspan="1">RFC 9290, <xref target="m
edia-type" format="default" sectionFormat="of" derivedContent="Section 6.3"/></t
d>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<dl spacing="compact"> <dl indent="3" newline="false" spacing="normal" pn="section-6.3-3">
<dt>Type name:</dt> <dt pn="section-6.3-3.1">Type name:</dt>
<dd> <dd pn="section-6.3-3.2">
<t>application</t> <t indent="0" pn="section-6.3-3.2.1">application</t>
</dd> </dd>
<dt>Subtype name:</dt> <dt pn="section-6.3-3.3">Subtype name:</dt>
<dd> <dd pn="section-6.3-3.4">
<t>concise-problem-details+cbor</t> <t indent="0" pn="section-6.3-3.4.1">concise-problem-details+cbor</t
>
</dd> </dd>
<dt>Required parameters:</dt> <dt pn="section-6.3-3.5">Required parameters:</dt>
<dd> <dd pn="section-6.3-3.6">
<t>N/A</t> <t indent="0" pn="section-6.3-3.6.1">N/A</t>
</dd> </dd>
<dt>Optional parameters:</dt> <dt pn="section-6.3-3.7">Optional parameters:</dt>
<dd> <dd pn="section-6.3-3.8">
<t>N/A</t> <t indent="0" pn="section-6.3-3.8.1">N/A</t>
</dd> </dd>
<dt>Encoding considerations:</dt> <dt pn="section-6.3-3.9">Encoding considerations:</dt>
<dd> <dd pn="section-6.3-3.10">
<t>binary (CBOR data item)</t> <t indent="0" pn="section-6.3-3.10.1">binary (CBOR data item)</t>
</dd> </dd>
<dt>Security considerations:</dt> <dt pn="section-6.3-3.11">Security considerations:</dt>
<dd> <dd pn="section-6.3-3.12">
<t><xref target="seccons"/> of RFC XXXX</t> <t indent="0" pn="section-6.3-3.12.1"><xref target="seccons" format=
"default" sectionFormat="of" derivedContent="Section 5"/> of RFC 9290</t>
</dd> </dd>
<dt>Interoperability considerations:</dt> <dt pn="section-6.3-3.13">Interoperability considerations:</dt>
<dd> <dd pn="section-6.3-3.14">
<t>none</t> <t indent="0" pn="section-6.3-3.14.1">none</t>
</dd> </dd>
<dt>Published specification:</dt> <dt pn="section-6.3-3.15">Published specification:</dt>
<dd> <dd pn="section-6.3-3.16">
<t><xref target="media-type"/> of RFC XXXX</t> <t indent="0" pn="section-6.3-3.16.1"><xref target="media-type" form
at="default" sectionFormat="of" derivedContent="Section 6.3"/> of RFC 9290</t>
</dd> </dd>
<dt>Applications that use this media type:</dt> <dt pn="section-6.3-3.17">Applications that use this media type:</dt>
<dd> <dd pn="section-6.3-3.18">
<t>Clients and servers in the Internet of Things</t> <t indent="0" pn="section-6.3-3.18.1">Clients and servers in the Int
ernet of Things</t>
</dd> </dd>
<dt>Fragment identifier considerations:</dt> <dt pn="section-6.3-3.19">Fragment identifier considerations:</dt>
<dd> <dd pn="section-6.3-3.20">
<t>The syntax and semantics of fragment identifiers is as specified <t indent="0" pn="section-6.3-3.20.1">The syntax and semantics of fr
for agment identifiers is as specified for
"application/cbor". (At publication of RFC XXXX, there is no "application/cbor". (At publication of RFC 9290, there is no
fragment identification syntax defined for "application/cbor".)</t> fragment identification syntax defined for "application/cbor".)</t>
</dd> </dd>
<dt>Person &amp; email address to contact for further information:</dt <dt pn="section-6.3-3.21">Additional information:</dt>
> <dd pn="section-6.3-3.22">
<dd> <t indent="0" pn="section-6.3-3.22.1"><br/></t>
<t>CoRE WG mailing list (core@ietf.org), <dl spacing="compact" indent="3" newline="false" pn="section-6.3-3.2
2.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 fu
rther information:</dt>
<dd pn="section-6.3-3.24">
<t indent="0" pn="section-6.3-3.24.1">CoRE WG mailing list (core@iet
f.org)
or IETF Applications and Real-Time Area (art@ietf.org)</t> or IETF Applications and Real-Time Area (art@ietf.org)</t>
</dd> </dd>
<dt>Intended usage:</dt> <dt pn="section-6.3-3.25">Intended usage:</dt>
<dd> <dd pn="section-6.3-3.26">
<t>COMMON</t> <t indent="0" pn="section-6.3-3.26.1">COMMON</t>
</dd> </dd>
<dt>Restrictions on usage:</dt> <dt pn="section-6.3-3.27">Restrictions on usage:</dt>
<dd> <dd pn="section-6.3-3.28">
<t>none</t> <t indent="0" pn="section-6.3-3.28.1">none</t>
</dd> </dd>
<dt>Author/Change controller:</dt> <dt pn="section-6.3-3.29">Author/Change controller:</dt>
<dd> <dd pn="section-6.3-3.30">
<t>IETF</t> <t indent="0" pn="section-6.3-3.30.1">IETF</t>
</dd> </dd>
<dt>Provisional registration:</dt> <dt pn="section-6.3-3.31">Provisional registration:</dt>
<dd> <dd pn="section-6.3-3.32">
<t>no</t> <t indent="0" pn="section-6.3-3.32.1">no</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="content-format"> <section anchor="content-format" numbered="true" removeInRFC="false" toc="
<name>Content-Format</name> include" pn="section-6.4">
<t>IANA is requested to register a Content-Format number in the <name slugifiedName="name-content-format">Content-Format</name>
<xref section="&quot;CoAP Content-Formats&quot;" relative="#content-formats" sec <t indent="0" pn="section-6.4-1">IANA has registered a Content-Format nu
tionFormat="bare" target="IANA.core-parameters"/> mber in the
sub-registry, within the "Constrained RESTful Environments (CoRE) <xref section="&quot;CoAP Content-Formats&quot;" relative="#content-formats" sec
Parameters" Registry <xref target="IANA.core-parameters"/>, as follows:</t> tionFormat="bare" target="IANA.core-parameters" format="default" derivedLink="ht
<table align="left"> tps://www.iana.org/assignments/core-parameters#content-formats" derivedContent="
<name>New Content-Format</name> IANA.core-parameters"/>
subregistry, within the "Constrained RESTful Environments (CoRE)
Parameters" registry <xref target="IANA.core-parameters" format="default" sectio
nFormat="of" derivedContent="IANA.core-parameters"/>, as follows:</t>
<table align="left" pn="table-4">
<name slugifiedName="name-content-format-registration">Content-Format
Registration</name>
<thead> <thead>
<tr> <tr>
<th align="left">Content-Type</th> <th align="left" colspan="1" rowspan="1">Media Type</th>
<th align="left">Content Coding</th> <th align="left" colspan="1" rowspan="1">Encoding</th>
<th align="left">ID</th> <th align="left" colspan="1" rowspan="1">ID</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">application/concise-problem-details+cbor</td> <td align="left" colspan="1" rowspan="1">application/concise-probl
<td align="left">-</td> em-details+cbor</td>
<td align="left">TBD1</td> <td align="left" colspan="1" rowspan="1">-</td>
<td align="left">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">257</td>
<td align="left" colspan="1" rowspan="1">RFC 9290</td>
</tr> </tr>
</tbody> </tbody>
</table> </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 paragra
ph to be removed by RFC editor.</cref></t>
</section> </section>
<section anchor="iana-tag38"> <section anchor="iana-tag38" numbered="true" removeInRFC="false" toc="incl
<name>CBOR Tag 38</name> ude" pn="section-6.5">
<t>In the registry "<xref section="CBOR Tags" relative="#cbor-tags" sect <name slugifiedName="name-cbor-tag-38">CBOR Tag 38</name>
ionFormat="bare" target="IANA.cbor-tags"/>" <xref target="IANA.cbor-tags"/>, <t indent="0" pn="section-6.5-1">In the registry "<xref section="CBOR Ta
IANA has registered CBOR Tag 38. gs" relative="#cbor-tags" sectionFormat="bare" target="IANA.cbor-tags" format="d
IANA is requested to replace the reference for this registration with efault" derivedLink="https://www.iana.org/assignments/cbor-tags#cbor-tags" deriv
<xref target="tag38"/>, RFC XXXX.</t> edContent="IANA.cbor-tags"/>" <xref target="IANA.cbor-tags" format="default" sec
tionFormat="of" derivedContent="IANA.cbor-tags"/>,
IANA has registered CBOR tag 38.
IANA has updated the reference for CBOR tag 38 to point to RFC 9290, <xref targe
t="tag38" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.ietf-httpapi-rfc7807bis" to="HTTPAPI"/>
<name>References</name> <references pn="section-7">
<references> <name slugifiedName="name-references">References</name>
<name>Normative References</name> <references pn="section-7.1">
<reference anchor="STD94" target="https://www.rfc-editor.org/info/rfc894 <name slugifiedName="name-normative-references">Normative References</na
9"> me>
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme
nts/cbor-tags" quoteTitle="true" derivedAnchor="IANA.cbor-tags">
<front> <front>
<title>Concise Binary Object Representation (CBOR)</title> <title>Concise Binary Object Representation (CBOR) Tags</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"> <author>
<organization/> <organization abbrev="IANA" showOnFrontPage="true">Internet Assign
</author> ed Numbers Authority</organization>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author> </author>
<date month="December" year="2020"/> <date/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front> </front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference> </reference>
<reference anchor="STD66" target="https://www.rfc-editor.org/info/rfc398 6"> <reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters" quoteTitle="true" derivedAnchor="IANA.core-parameters ">
<front> <front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> <title>Constrained RESTful Environments (CoRE) Parameters</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee <author>
"> <organization abbrev="IANA" showOnFrontPage="true">Internet Assign
<organization/> ed Numbers Authority</organization>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author> </author>
<date month="January" year="2005"/> <date/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification d
efines the generic URI syntax and a process for resolving URI references that mi
ght be in relative form, along with guidelines and security considerations for t
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
rset of all valid URIs, allowing an implementation to parse the common component
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference> </reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7 252"> <reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/provisional-standard-media-types" quoteTitle="true" derivedAnchor="IANA.me dia-types">
<front> <front>
<title>The Constrained Application Protocol (CoAP)</title> <title>Provisional Standard Media Type Registry</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"> <author>
<organization/> <organization abbrev="IANA" showOnFrontPage="true">Internet Assign
</author> ed Numbers Authority</organization>
<author fullname="K. Hartke" initials="K." surname="Hartke">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author> </author>
<date month="June" year="2014"/> <date/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless Personal Area Networks (6LoWPANs) often have high packet error rates and a
typical throughput of 10s of kbit/s. The protocol is designed for machine- to-
machine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is d
esigned to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simp
licity for constrained environments.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference> </reference>
<reference anchor="RFC7807" target="https://www.rfc-editor.org/info/rfc7 807"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 119" quoteTitle="true" derivedAnchor="RFC2119">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> le>
<organization/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
</author> <date month="March" year="1997"/>
<author fullname="E. Wilde" initials="E." surname="Wilde">
<organization/>
</author>
<date month="March" year="2016"/>
<abstract> <abstract>
<t>This document defines a "problem detail" as a way to carry mach ine- readable details of errors in a HTTP response to avoid the need to define n ew error response formats for HTTP APIs.</t> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often ca pitalized. This document defines these words as they should be interpreted in I ETF documents. This document specifies an Internet Best Current Practices for t he Internet Community, and requests discussion and suggestions for improvements. </t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7807"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="DOI" value="10.17487/RFC7807"/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags"> <reference anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4 647" quoteTitle="true" derivedAnchor="RFC4647">
<front> <front>
<title>Concise Binary Object Representation (CBOR) Tags</title> <title>Matching of Language Tags</title>
<author> <author fullname="A. Phillips" initials="A." role="editor" surname="
<organization abbrev="IANA">Internet Assigned Numbers Authority</o Phillips"/>
rganization> <author fullname="M. Davis" initials="M." role="editor" surname="Dav
</author> is"/>
<date day="19" month="September" year="2013"/> <date month="September" year="2006"/>
<abstract>
<t indent="0">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 tag
s. Two kinds of matching mechanisms, filtering and lookup, are defined. Filter
ing produces a (potentially empty) set of language tags, whereas lookup produces
a single language tag. Possible applications include language negotiation or c
ontent selection. This document, in combination with RFC 4646, replaces RFC 306
6, which replaced RFC 1766. This document specifies an Internet Best Current Pr
actices for the Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="4647"/>
<seriesInfo name="DOI" value="10.17487/RFC4647"/>
</reference> </reference>
<reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5 646"> <reference anchor="RFC5646" target="https://www.rfc-editor.org/info/rfc5 646" quoteTitle="true" derivedAnchor="RFC5646">
<front> <front>
<title>Tags for Identifying Languages</title> <title>Tags for Identifying Languages</title>
<author fullname="A. Phillips" initials="A." role="editor" surname=" <author fullname="A. Phillips" initials="A." role="editor" surname="
Phillips"> Phillips"/>
<organization/> <author fullname="M. Davis" initials="M." role="editor" surname="Dav
</author> is"/>
<author fullname="M. Davis" initials="M." role="editor" surname="Dav
is">
<organization/>
</author>
<date month="September" year="2009"/> <date month="September" year="2009"/>
<abstract> <abstract>
<t>This document describes the structure, content, construction, a nd semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practice s for the Internet Community, and requests discussion and suggestions for improv ements.</t> <t indent="0">This document describes the structure, content, cons truction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how t o register values for use in language tags and the creation of user-defined exte nsions for private interchange. This document specifies an Internet Best Curren t Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="47"/> <seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="5646"/> <seriesInfo name="RFC" value="5646"/>
<seriesInfo name="DOI" value="10.17487/RFC5646"/> <seriesInfo name="DOI" value="10.17487/RFC5646"/>
</reference> </reference>
<reference anchor="RFC4647" target="https://www.rfc-editor.org/info/rfc4 <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
647"> 252" quoteTitle="true" derivedAnchor="RFC7252">
<front>
<title>Matching of Language Tags</title>
<author fullname="A. Phillips" initials="A." role="editor" surname="
Phillips">
<organization/>
</author>
<author fullname="M. Davis" initials="M." role="editor" surname="Dav
is">
<organization/>
</author>
<date month="September" year="2006"/>
<abstract>
<t>This document describes a syntax, called a "language-range", fo
r specifying items in a user's list of language preferences. It also describes
different mechanisms for comparing and matching these to language tags. Two kin
ds of matching mechanisms, filtering and lookup, are defined. Filtering produce
s a (potentially empty) set of language tags, whereas lookup produces a single l
anguage tag. Possible applications include language negotiation or content selec
tion. This document, in combination with RFC 4646, replaces RFC 3066, which rep
laced RFC 1766. This document specifies an Internet Best Current Practices for
the Internet Community, and requests discussion and suggestions for improvements
.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="4647"/>
<seriesInfo name="DOI" value="10.17487/RFC4647"/>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610">
<front> <front>
<title>Concise Data Definition Language (CDDL): A Notational Convent <title>The Constrained Application Protocol (CoAP)</title>
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
res</title> <author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="H. Birkholz" initials="H." surname="Birkholz"> <author fullname="C. Bormann" initials="C." surname="Bormann"/>
<organization/> <date month="June" year="2014"/>
</author>
<author fullname="C. Vigano" initials="C." surname="Vigano">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="June" year="2019"/>
<abstract> <abstract>
<t>This document proposes a notational convention to express Conci <t indent="0">The Constrained Application Protocol (CoAP) is a spe
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa cialized web transfer protocol for use with constrained nodes and constrained (e
l is to provide an easy and unambiguous way to express structures for protocol m .g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers wit
essages and data formats that use CBOR or JSON.</t> h 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 r
ates and a typical throughput of 10s of kbit/s. The protocol is designed for mac
hine- to-machine (M2M) applications such as smart energy and building automation
.</t>
<t indent="0">CoAP provides a request/response interaction model b
etween application endpoints, supports built-in discovery of services and resour
ces, 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 whi
le meeting specialized requirements such as multicast support, very low overhead
, and simplicity for constrained environments.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="8610"/> <seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference> </reference>
<reference anchor="RFC9165" target="https://www.rfc-editor.org/info/rfc9 165"> <reference anchor="RFC7807" target="https://www.rfc-editor.org/info/rfc7 807" quoteTitle="true" derivedAnchor="RFC7807">
<front> <front>
<title>Additional Control Operators for the Concise Data Definition <title>Problem Details for HTTP APIs</title>
Language (CDDL)</title> <author fullname="M. Nottingham" initials="M." surname="Nottingham"/
<author fullname="C. Bormann" initials="C." surname="Bormann"> >
<organization/> <author fullname="E. Wilde" initials="E." surname="Wilde"/>
</author> <date month="March" year="2016"/>
<date month="December" year="2021"/>
<abstract> <abstract>
<t>The Concise Data Definition Language (CDDL), standardized in RF <t indent="0">This document defines a "problem detail" as a way to
C 8610, provides "control operators" as its main language extension point.</t> carry machine- readable details of errors in a HTTP response to avoid the need
<t>The present document defines a number of control operators that to define new error response formats for HTTP APIs.</t>
were not yet ready at the time RFC 8610 was completed: , , and for the constru
ction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifi
cations; and for indicating the use of a non-basic feature in an instance.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="9165"/> <seriesInfo name="RFC" value="7807"/>
<seriesInfo name="DOI" value="10.17487/RFC9165"/> <seriesInfo name="DOI" value="10.17487/RFC7807"/>
</reference> </reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8 126"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8 126" quoteTitle="true" derivedAnchor="RFC8126">
<front> <front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs </title> <title>Guidelines for Writing an IANA Considerations Section in RFCs </title>
<author fullname="M. Cotton" initials="M." surname="Cotton"> <author fullname="M. Cotton" initials="M." surname="Cotton"/>
<organization/> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
</author> <author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<date month="June" year="2017"/> <date month="June" year="2017"/>
<abstract> <abstract>
<t>Many protocols make use of points of extensibility that use con <t indent="0">Many protocols make use of points of extensibility t
stants to identify various protocol parameters. To ensure that the values in th hat use constants to identify various protocol parameters. To ensure that the va
ese fields do not have conflicting uses and to promote interoperability, their a lues in these fields do not have conflicting uses and to promote interoperabilit
llocations are often coordinated by a central record keeper. For IETF protocols y, their allocations are often coordinated by a central record keeper. For IETF
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
<t>To make assignments in a given registry prudently, guidance des .</t>
cribing the conditions under which new values should be assigned, as well as whe <t indent="0">To make assignments in a given registry prudently, g
n and how modifications to existing values can be made, is needed. This documen uidance describing the conditions under which new values should be assigned, as
t defines a framework for the documentation of these guidelines by specification well as when and how modifications to existing values can be made, is needed. Th
authors, in order to assure that the provided guidance for the IANA Considerati is document defines a framework for the documentation of these guidelines by spe
ons is clear and addresses the various issues that are likely in the operation o cification authors, in order to assure that the provided guidance for the IANA C
f a registry.</t> onsiderations is clear and addresses the various issues that are likely in the o
<t>This is the third edition of this document; it obsoletes RFC 52 peration of a registry.</t>
26.</t> <t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/> <seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/> <seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
119"> 174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"> <author fullname="B. Leiba" initials="B." surname="Leiba"/>
<organization/>
</author>
<date month="May" year="2017"/> <date month="May" year="2017"/>
<abstract> <abstract>
<t>RFC 2119 specifies common key words that may be used in protoco l specifications. This document aims to reduce the ambiguity by clarifying tha t only UPPERCASE usage of the key words have the defined special meanings.</t> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clar ifying that only UPPERCASE usage of the key words have the defined special meani ngs.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<reference anchor="IANA.core-parameters" target="https://www.iana.org/as <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
signments/core-parameters"> 610" quoteTitle="true" derivedAnchor="RFC8610">
<front>
<title>Constrained RESTful Environments (CoRE) Parameters</title>
<author>
<organization abbrev="IANA">Internet Assigned Numbers Authority</o
rganization>
</author>
<date day="8" month="June" year="2012"/>
</front>
</reference>
<reference anchor="IANA.media-types" target="https://www.iana.org/assign
ments/provisional-standard-media-types">
<front> <front>
<title>Provisional Standard Media Type Registry</title> <title>Concise Data Definition Language (CDDL): A Notational Convent
<author> ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
<organization abbrev="IANA">Internet Assigned Numbers Authority</o res</title>
rganization> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
</author> <author fullname="C. Vigano" initials="C." surname="Vigano"/>
<date day="20" month="July" year="2012"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2019"/>
<abstract>
<t indent="0">This document proposes a notational convention to ex
press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I
ts 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> </front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference> </reference>
</references> <reference anchor="RFC9165" target="https://www.rfc-editor.org/info/rfc9
<references> 165" quoteTitle="true" derivedAnchor="RFC9165">
<name>Informative References</name>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648">
<front> <front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <title>Additional Control Operators for the Concise Data Definition
<author fullname="S. Josefsson" initials="S." surname="Josefsson"> Language (CDDL)</title>
<organization/> <author fullname="C. Bormann" initials="C." surname="Bormann"/>
</author> <date month="December" year="2021"/>
<date month="October" year="2006"/>
<abstract> <abstract>
<t>This document describes the commonly used base 64, base 32, and <t indent="0">The Concise Data Definition Language (CDDL), standar
base 16 encoding schemes. It also discusses the use of line-feeds in encoded d dized in RFC 8610, provides "control operators" as its main language extension p
ata, use of padding in encoded data, use of non-alphabet characters in encoded d oint.</t>
ata, use of different encoding alphabets, and canonical encodings. [STANDARDS-T <t indent="0">The present document defines a number of control ope
RACK]</t> rators that were not yet ready at the time RFC 8610 was completed: , , and for t
he construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CD
DL specifications; and for indicating the use of a non-basic feature in an insta
nce.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4648"/> <seriesInfo name="RFC" value="9165"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/> <seriesInfo name="DOI" value="10.17487/RFC9165"/>
</reference> </reference>
<reference anchor="I-D.ietf-httpapi-rfc7807bis" target="https://www.ietf <referencegroup anchor="STD66" target="https://www.rfc-editor.org/info/s
.org/archive/id/draft-ietf-httpapi-rfc7807bis-03.txt"> td66" derivedAnchor="STD66">
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rf
c3986" quoteTitle="true">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-L
ee"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t indent="0">A Uniform Resource Identifier (URI) is a compact s
equence of characters that identifies an abstract or physical resource. This sp
ecification defines the generic URI syntax and a process for resolving URI refer
ences that might be in relative form, along with guidelines and security conside
rations for the use of URIs on the Internet. The URI syntax defines a grammar t
hat is a superset of all valid URIs, allowing an implementation to parse the com
mon components of a URI reference without knowing the scheme-specific requiremen
ts of every possible identifier. This specification does not define a generativ
e grammar for URIs; that task is performed by the individual specifications of e
ach URI scheme. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
</referencegroup>
<referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/s
td94" derivedAnchor="STD94">
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rf
c8949" quoteTitle="true">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t indent="0">The Concise Binary Object Representation (CBOR) is
a data format whose design goals include the possibility of extremely small cod
e size, fairly small message size, and extensibility without the need for versio
n negotiation. These design goals make it different from earlier binary serializ
ations such as ASN.1 and MessagePack.</t>
<t indent="0">This document obsoletes RFC 7049, providing editor
ial 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 th
e format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
</referencegroup>
</references>
<references pn="section-7.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.ietf-httpapi-rfc7807bis" quoteTitle="true" target
="https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-rfc7807bis-04" derive
dAnchor="HTTPAPI">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>Problem Details for HTTP APIs</title>
<author fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham
</author> ">
<author fullname="Erik Wilde"> </author>
</author> <author initials="E." surname="Wilde" fullname="Erik Wilde">
<author fullname="Sanjay Dalal"> </author>
</author> <author initials="S." surname="Dalal" fullname="Sanjay Dalal">
<date day="25" month="May" year="2022"/> </author>
<date month="September" day="5" year="2022"/>
<abstract> <abstract>
<t> This document defines a "problem detail" to carry machine-re adable <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 details of errors in HTTP response content and/or fields to avoid the
need to define new error response formats for HTTP APIs. need to define new error response formats for HTTP APIs.
This document obsoletes RF7807.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-httpapi/rfc7807bis. https://github.com/ietf-wg-httpapi/rfc7807bis.
</t> </t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis
-03"/> -04"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
httpapi-rfc7807bis-04.txt"/>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="RDF" target="http://www.w3.org/TR/2014/REC-rdf11-conc epts-20140225/"> <reference anchor="RDF" target="http://www.w3.org/TR/2014/REC-rdf11-conc epts-20140225/" quoteTitle="true" derivedAnchor="RDF">
<front> <front>
<title>RDF 1.1 Concepts and Abstract Syntax</title> <title>RDF 1.1 Concepts and Abstract Syntax</title>
<author initials="R." surname="Cyganiak" fullname="Richard Cyganiak" > <author initials="R." surname="Cyganiak" fullname="Richard Cyganiak" >
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="D." surname="Wood" fullname="David Wood"> <author initials="D." surname="Wood" fullname="David Wood">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Lanthaler" fullname="Markus Lanthaler "> <author initials="M." surname="Lanthaler" fullname="Markus Lanthaler ">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2014" month="February" day="25"/> <date year="2014" month="February" day="25"/>
</front> </front>
<refcontent>W3C Recommendation</refcontent> <refcontent>W3C Recommendation</refcontent>
</reference> </reference>
<reference anchor="RFC6082" target="https://www.rfc-editor.org/info/rfc6 <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
082"> 648" 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, b
ase 32, and base 16 encoding schemes. It also discusses the use of line-feeds i
n encoded data, use of padding in encoded data, use of non-alphabet characters i
n encoded data, use of different encoding alphabets, and canonical encodings. [S
TANDARDS-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/rfc6
082" quoteTitle="true" derivedAnchor="RFC6082">
<front> <front>
<title>Deprecating Unicode Language Tag Characters: RFC 2482 is Hist oric</title> <title>Deprecating Unicode Language Tag Characters: RFC 2482 is Hist oric</title>
<author fullname="K. Whistler" initials="K." surname="Whistler"> <author fullname="K. Whistler" initials="K." surname="Whistler"/>
<organization/> <author fullname="G. Adams" initials="G." surname="Adams"/>
</author> <author fullname="M. Duerst" initials="M." surname="Duerst"/>
<author fullname="G. Adams" initials="G." surname="Adams"> <author fullname="R. Presuhn" initials="R." role="editor" surname="P
<organization/> resuhn"/>
</author> <author fullname="J. Klensin" initials="J." surname="Klensin"/>
<author fullname="M. Duerst" initials="M." surname="Duerst">
<organization/>
</author>
<author fullname="R. Presuhn" initials="R." role="editor" surname="P
resuhn">
<organization/>
</author>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="November" year="2010"/> <date month="November" year="2010"/>
<abstract> <abstract>
<t>RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languag es when needed without more general markup such as that provided by XML. The Un icode Consortium has deprecated that facility and strongly recommends against it s use. RFC 2482 has been moved to Historic status to reduce the possibility tha t Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specif ication; it is published for informational purposes.</t> <t indent="0">RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to ident ify languages when needed without more general markup such as that provided by X ML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the poss ibility that Internet implementers would consider that system an appropriate mec hanism for identifying languages. This document is not an Internet Standards Tr ack specification; it is published for informational purposes.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="6082"/> <seriesInfo name="RFC" value="6082"/>
<seriesInfo name="DOI" value="10.17487/RFC6082"/> <seriesInfo name="DOI" value="10.17487/RFC6082"/>
</reference> </reference>
<reference anchor="Unicode-14.0.0" target="https://www.unicode.org/versi ons/Unicode14.0.0/"> <reference anchor="Unicode-14.0.0" target="https://www.unicode.org/versi ons/Unicode14.0.0/" quoteTitle="true" derivedAnchor="Unicode-14.0.0">
<front> <front>
<title>The Unicode Standard, Version 14.0.0</title> <title>The Unicode Standard, Version 14.0.0</title>
<author> <author>
<organization>The Unicode Consortium</organization> <organization showOnFrontPage="true">The Unicode Consortium</organ ization>
</author> </author>
<date year="2021" month="September"/> <date year="2021" month="September"/>
</front> </front>
<seriesInfo name="ISBN" value="978-1-936213-29-0"/> <seriesInfo name="ISBN" value="978-1-936213-29-0"/>
<annotation>Note that while this document references a version that wa s recent at the time of writing, the statements made based on this version are e xpected to remain valid for future versions.</annotation>
<refcontent>Mountain View: The Unicode Consortium</refcontent> <refcontent>Mountain View: The Unicode Consortium</refcontent>
</reference> </reference>
<reference anchor="Unicode-14.0.0-bidi" target="https://www.unicode.org/ reports/tr9/#Markup_And_Formatting"> <reference anchor="Unicode-14.0.0-bidi" target="https://www.unicode.org/ reports/tr9/#Markup_And_Formatting" quoteTitle="true" derivedAnchor="Unicode-14. 0.0-bidi">
<front> <front>
<title>Unicode® Standard Annex #9 --- Unicode Bidirectional Algorith m</title> <title>Unicode Standard Annex #9 --- Unicode Bidirectional Algorithm </title>
<author> <author>
<organization>The Unicode Consortium</organization> <organization showOnFrontPage="true">The Unicode Consortium</organ ization>
</author> </author>
<date year="2021" month="August" day="27"/> <date year="2021" month="August" day="27"/>
</front> </front>
<annotation>Note that while this document references a version that wa s recent at the time of writing, the statements made based on this version are e xpected to remain valid for future versions.</annotation>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="tag38"> <section anchor="tag38" numbered="true" removeInRFC="false" toc="include" pn
<name>Language-Tagged Strings</name> ="section-appendix.a">
<t>This appendix serves as the archival documentation for CBOR Tag 38, a <name slugifiedName="name-language-tagged-strings">Language-Tagged Strings
</name>
<t indent="0" pn="section-appendix.a-1">This appendix serves as the archiv
al documentation for CBOR tag 38, a
tag for serializing language-tagged text strings in CBOR. tag for serializing language-tagged text strings in CBOR.
The text of this appendix is adapted from the specification text The text of this appendix is adapted from the specification text
supplied for its initial registration. supplied for its initial registration.
It has been extended to allow supplementing the language tag by a It has been extended to allow supplementing the language tag by a
direction indication.</t> direction indication.</t>
<t>As with any IANA-registered item, a specification that further updates this <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 registration needs to update the reference column of the IANA registry (see
<xref target="iana-tag38"/>). <xref target="iana-tag38" format="default" sectionFormat="of" derivedContent="Se ction 6.5"/>).
Future specifications may update this appendix, other parts of this document, Future specifications may update this appendix, other parts of this document,
or both. or both.
(When updating this appendix, keep in mind that applications beyond (When updating this appendix, keep in mind that applications beyond
concise problem details may adopt the tag defined here.) Concise Problem Details data items may adopt the tag defined here.)
Users of this tag are advised to consult the registry to obtain the Users of this tag are advised to consult the registry to obtain the
most recent update for this appendix.</t> most recent update for this appendix.</t>
<section anchor="introduction-1"> <section anchor="introduction-1" numbered="true" removeInRFC="false" toc="
<name>Introduction</name> include" pn="section-appendix.a.1">
<t>In some cases it is useful to specify the natural language of a text <name slugifiedName="name-introduction-2">Introduction</name>
<t indent="0" pn="section-appendix.a.1-1">In some cases, it is useful to
specify the natural language of a text
string. This specification defines a tag that does just that. One string. This specification defines a tag that does just that. One
technology that supports language-tagged strings is the Resource technology that supports language-tagged strings is the Resource
Description Framework (RDF) <xref target="RDF"/>.</t> Description Framework (RDF) <xref target="RDF" format="default" sectionFormat="o f" derivedContent="RDF"/>.</t>
</section> </section>
<section anchor="detailed-semantics"> <section anchor="detailed-semantics" numbered="true" removeInRFC="false" t
<name>Detailed Semantics</name> oc="include" pn="section-appendix.a.2">
<t>A language-tagged string in CBOR has the tag 38 and consists of an ar <name slugifiedName="name-detailed-semantics">Detailed Semantics</name>
ray <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> with a length of 2 or 3.</t>
<t>The first element is a well-formed language tag under Best Current <t indent="0" pn="section-appendix.a.2-2">The first element is a well-fo
Practice 47 (<xref target="RFC5646"/> and <xref target="RFC4647"/>), represented rmed language tag described in BCP 47 (<xref target="RFC5646" format="default" s
as a UTF-8 text ectionFormat="of" derivedContent="RFC5646"/> and <xref target="RFC4647" format="
default" sectionFormat="of" derivedContent="RFC4647"/>), represented as a UTF-8
text
string (major type 3).</t> string (major type 3).</t>
<t>The second element is an arbitrary UTF-8 text string (major type <t indent="0" pn="section-appendix.a.2-3">The second element is an arbit rary UTF-8 text string (major type
3). Both the language tag and the arbitrary string can optionally be 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> annotated with CBOR tags; this is not shown in the CDDL below.</t>
<t>The optional third element, if present, represents a ternary value th at <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> indicates a direction, as follows:</t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-a
<li> ppendix.a.2-5">
<li pn="section-appendix.a.2-5.1">
<tt>false</tt>: left-to-right direction ("ltr"). <tt>false</tt>: left-to-right direction ("ltr").
The text is expected to be displayed with left-to-right base The text is expected to be displayed with left-to-right base
direction if standalone, and isolated with left-to-right direction direction if standalone and isolated with left-to-right direction
(as if enclosed in LRI ... PDI or equivalent, see <xref target="Unicode-14.0.0-b (as if enclosed in LRI ... PDI or equivalent, see <xref target="Unicode-14.0.0-b
idi"/>) in the idi" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0-bidi"/>)
in the
context of a longer string or text.</li> 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"). <tt>true</tt>: right-to-left direction ("rtl").
The text is expected to be displayed with right-to-left base The text is expected to be displayed with right-to-left base
direction if standalone, and isolated with right-to-left direction direction if standalone and isolated with right-to-left direction
(as if enclosed in RLI ... PDI or equivalent, see <xref target="Unicode-14.0.0-b (as if enclosed in RLI ... PDI or equivalent, see <xref target="Unicode-14.0.0-b
idi"/>) in the context idi" format="default" sectionFormat="of" derivedContent="Unicode-14.0.0-bidi"/>)
in the context
of a longer string or text.</li> of a longer string or text.</li>
<li> <li pn="section-appendix.a.2-5.3">
<tt>null</tt> indicates that no indication is made about the directi <tt>null:</tt> indicates that no indication is made about the direct
on ion
("auto"), enabling an internationalization library to make an auto-detection ("auto"), enabling an internationalization library to make an auto-detection
decision such as treating the string as if enclosed in FSI ... PDI decision such as treating the string as if enclosed in FSI ... PDI
or equivalent, see <xref target="Unicode-14.0.0-bidi"/>.</li> or equivalent, see <xref target="Unicode-14.0.0-bidi" format="default" sectionFo rmat="of" derivedContent="Unicode-14.0.0-bidi"/>.</li>
</ul> </ul>
<t>If the third element is absent, directionality context may be applyin <t indent="0" pn="section-appendix.a.2-6">If the third element is absent
g , directionality context may be applied
(e.g., base directionality information for an entire CBOR message or (e.g., base-directionality information for an entire CBOR message or
part thereof). If there is no directionality context applying, the part thereof). If there is no directionality context applied, the
default interpretation is the same as for <tt>null</tt> ("auto").</t> default interpretation is the same as for <tt>null</tt> ("auto").</t>
<t>In CDDL:</t> <t indent="0" pn="section-appendix.a.2-7">In CDDL:</t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl" markers="false" pn="section-appendix.a.2-8">
tag38 = #6.38([tag38-ltag, text, ?tag38-direction]) tag38 = #6.38([tag38-ltag, text, ?tag38-direction])
tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*" tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
tag38-direction = &(ltr: false, rtl: true, auto: null) tag38-direction = &amp;(ltr: false, rtl: true, auto: null)
]]></sourcecode> </sourcecode>
<!-- RUBY_THREAD_VM_STACK_SIZE=5000000 cddl ... --> <t indent="0" pn="section-appendix.a.2-9">NOTE: Language tags of any com
bination of case are allowed. But
<t>NOTE: Language tags of any combination of case are allowed. But <xref section="2.1.1" sectionFormat="of" target="RFC5646" format="default" deriv
<xref section="2.1.1" sectionFormat="of" target="RFC5646"/>, part of Best Curren edLink="https://rfc-editor.org/rfc/rfc5646#section-2.1.1" derivedContent="RFC564
t Practice 47, 6"/>, part of BCP 47,
recommends a case combination for language tags that encoders that recommends a case combination for language tags that encoders that
support tag 38 may wish to follow when generating language tags.</t> support tag 38 may wish to follow when generating language tags.</t>
<t>Data items with tag 38 that do not meet the criteria above are not va <t indent="0" pn="section-appendix.a.2-10">Data items with tag 38 that d
lid o not meet the criteria above are not valid
(see <xref section="5.3.2" sectionFormat="of" target="STD94"/>).</t> (see Section <xref section="5.3.2" sectionFormat="bare" target="RFC8949" format=
<t>NOTE: The Unicode Standard <xref target="Unicode-14.0.0"/> includes a "default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-5.3.2" derived
set of characters Content="RFC8949"/> of RFC 8949 <xref target="STD94" format="default" sectionFor
designed for tagging text (including language tagging), in the range mat="of" derivedContent="STD94"/>).</t>
<t indent="0" pn="section-appendix.a.2-11">NOTE: The Unicode Standard <x
ref 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) in the range
U+E0000 to U+E007F. Although many applications, including RDF, U+E0000 to U+E007F. Although many applications, including RDF,
do not disallow these characters in text strings, the Unicode Consortium do not disallow these characters in text strings, the Unicode Consortium
has deprecated these characters and recommends annotating language via a has deprecated these characters and recommends annotating language via a
higher-level protocol instead. See the section "Deprecated Tag higher-level protocol instead. See the section "Deprecated Tag
Characters" in Section 23.9 of <xref target="Unicode-14.0.0"/>, as well as <xref Characters" in Section 23.9 of <xref target="Unicode-14.0.0" format="default" se
target="RFC6082"/>.</t> ctionFormat="of" derivedContent="Unicode-14.0.0"/> as well as <xref target="RFC6
082" format="default" sectionFormat="of" derivedContent="RFC6082"/>.</t>
<t indent="0" pn="section-appendix.a.2-12">NOTE: while this document ref
erences 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>
<section anchor="examples"> <section anchor="examples" numbered="true" removeInRFC="false" toc="includ
<name>Examples</name> e" pn="section-appendix.a.3">
<t>Examples in this section are given in CBOR diagnostic notation first <name slugifiedName="name-examples">Examples</name>
and then <t indent="0" pn="section-appendix.a.3-1">Examples in this section are g
iven in CBOR diagnostic notation first and then
as a pretty-printed hexadecimal representation of the encoded item.</t> as a pretty-printed hexadecimal representation of the encoded item.</t>
<t>The following example shows how the English-language string "Hello" i s <t indent="0" pn="section-appendix.a.3-2">The following example shows ho w the English-language string "Hello" is
represented.</t> represented.</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag" markers="false" pn="section-appendix.a.3-3" >
38(["en", "Hello"]) 38(["en", "Hello"])
]]></sourcecode> </sourcecode>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty" markers="false" pn="section-appendix.a.3-
4">
D8 26 # tag(38) D8 26 # tag(38)
82 # array(2) 82 # array(2)
62 # text(2) 62 # text(2)
656E # "en" 656E # "en"
65 # text(5) 65 # text(5)
48656C6C6F # "Hello" 48656C6C6F # "Hello"
]]></sourcecode> </sourcecode>
<t>The following example shows how the French-language string "Bonjour" <t indent="0" pn="section-appendix.a.3-5">The following example shows ho
is w the French-language string "Bonjour" is
represented.</t> represented.</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag" markers="false" pn="section-appendix.a.3-6" >
38(["fr", "Bonjour"]) 38(["fr", "Bonjour"])
]]></sourcecode> </sourcecode>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty" markers="false" pn="section-appendix.a.3-
7">
D8 26 # tag(38) D8 26 # tag(38)
82 # array(2) 82 # array(2)
62 # text(2) 62 # text(2)
6672 # "fr" 6672 # "fr"
67 # text(7) 67 # text(7)
426F6E6A6F7572 # "Bonjour" 426F6E6A6F7572 # "Bonjour"
]]></sourcecode> </sourcecode>
<t>The following example shows how the Hebrew-language string <t indent="0" pn="section-appendix.a.3-8">The following example uses rig
<u>שלום</u> is represented. ht-to-left (RTL) script, which in the context of this specification may be rende
red differently by different document presentation environments. The descriptiv
e text may be more reliable to follow than the necessarily device- and applicati
on-specific rendering.
The example shows how the Hebrew-language 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 dire
ction 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 ar ray to "true".</t> Note the <tt>rtl</tt> direction expressed by setting the third element in the ar ray to "true".</t>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag" markers="false" pn="section-appendix.a.3-11 ">
38(["he", "שלום", true]) 38(["he", "שלום", true])
]]></sourcecode> </sourcecode>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty" markers="false" pn="section-appendix.a.3-
12">
D8 26 # tag(38) D8 26 # tag(38)
83 # array(3) 83 # array(3)
62 # text(2) 62 # text(2)
6865 # "he" 6865 # "he"
68 # text(8) 68 # text(8)
D7A9D79CD795D79D # "שלום" D7A9D79CD795D79D # "שלום"
F5 # primitive(21) F5 # primitive(21)
]]></sourcecode> </sourcecode>
</section> </section>
</section> </section>
<section anchor="comp7807"> <section anchor="comp7807" numbered="true" removeInRFC="false" toc="include"
<name>Interworking with RFC 7807</name> pn="section-appendix.b">
<t>On certain occasions, it will be necessary to carry ("tunnel") <name slugifiedName="name-interworking-with-rfc-7807">Interworking with RF
<xref target="RFC7807"/> problem details in a Concise Problem Details data item. C 7807</name>
</t> <t indent="0" pn="section-appendix.b-1">On certain occasions, it will be n
<t>This appendix defines a Custom Problem Details entry for that purpose. ecessary to carry ("tunnel")
This is assigned Custom Problem Detail key 7807 in <xref target="iana-cpdk"/>. <xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC78
07"/> problem details in a Concise Problem Details data item.</t>
<t indent="0" pn="section-appendix.b-2">This appendix defines a Custom Pro
blem Detail entry for that purpose.
This is assigned Custom Problem Detail key 7807 in <xref target="iana-cpdk" form
at="default" sectionFormat="of" derivedContent="Section 6.2"/>.
Its structure is:</t> Its structure is:</t>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl" markers="false" pn="section-appendix.b-3">
tunnel-7807 = { tunnel-7807 = {
? &(type: 0) => ~uri ? &amp;(type: 0) =&gt; ~uri
? &(status: 1) => 0..999 ? &amp;(status: 1) =&gt; 0..999
* text => any * text =&gt; any
} }
]]></sourcecode> </sourcecode>
<t>To carry an <xref target="RFC7807"/> problem details JSON object in a C <t indent="0" pn="section-appendix.b-4">To carry an <xref target="RFC7807"
oncise Problem format="default" sectionFormat="of" derivedContent="RFC7807"/> problem details
Details data item, first convert the JSON object to CBOR as per <xref section="6 JSON object in a Concise Problem
.2" sectionFormat="of" target="STD94"/>. Create an empty Concise Problem Detail Details data item, first convert the JSON object to CBOR as per Section <xref se
s data item.</t> ction="6.2" sectionFormat="bare" target="RFC8949" format="default" derivedLink="
<t>Move the values for "title", "detail", and "instance", if present, https://rfc-editor.org/rfc/rfc8949#section-6.2" derivedContent="RFC8949"/> of RF
from the <xref target="RFC7807"/> problem details to the equivalent Standard Pro C 8949 <xref target="STD94" format="default" sectionFormat="of" derivedContent="
blem STD94"/>. Create an empty Concise Problem Details data item.</t>
<t indent="0" pn="section-appendix.b-5">Move the values for "title", "deta
il", and "instance", if present,
from the <xref target="RFC7807" format="default" sectionFormat="of" derivedConte
nt="RFC7807"/> problem details to the equivalent Standard Problem
Detail entries. Detail entries.
Create a Custom Problem Details entry with key 7807. Create a Custom Problem Detail entry with key 7807.
Move the values for "type" and "status", if present, to the equivalent Move the values for "type" and "status", if present, to the equivalent
keys 0 and 1 of the Custom Problem Details entry. keys 0 and 1 of the Custom Problem Detail entry.
Move all remaining key/value pairs (additional members as per <xref section="3.2 Move all remaining key/value pairs (additional members as per <xref section="3.2
" sectionFormat="of" target="RFC7807"/>) in the converted <xref target="RFC7807" " sectionFormat="of" target="RFC7807" format="default" derivedLink="https://rfc-
/> problem editor.org/rfc/rfc7807#section-3.2" derivedContent="RFC7807"/>) in the converted
details object to the Custom Problem Details map unchanged.</t> <xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC7
<t>The inverse direction, carrying Concise Problem Details in a Problem 807"/> problem
Details JSON object requires the additional support provided by details object to the Custom Problem Detail map unchanged.</t>
<xref target="I-D.ietf-httpapi-rfc7807bis"/>, which is planned to create the HTT <t indent="0" pn="section-appendix.b-6">The inverse direction, carrying Co
P Problem Types ncise Problem Details in an RFC 7807 problem
details JSON object requires the additional support provided by
<xref target="I-D.ietf-httpapi-rfc7807bis" format="default" sectionFormat="of" d
erivedContent="HTTPAPI"/>, which is planned to create the HTTP Problem Types
Registry. An HTTP Problem Type can then be registered that extracts 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 top-level items from the Concise Problem Details data item in a similar way
to the conversion described above, and which carries the rest of the to the conversion described above and that carries the rest of the
Concise Problem Details data item in an additional member via base64url Concise Problem Details data item in an additional member via base64url
encoding without padding (<xref section="5" sectionFormat="of" target="RFC4648"/ encoding without padding (<xref section="5" sectionFormat="of" target="RFC4648"
>). Details can be defined format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" deri
in a separate document when the work on <xref target="I-D.ietf-httpapi-rfc7807bi vedContent="RFC4648"/>). Details can be defined
s"/> is completed.</t> in a separate document when the work on <xref target="I-D.ietf-httpapi-rfc7807bi
s" format="default" sectionFormat="of" derivedContent="HTTPAPI"/> is completed.<
/t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="
<name>Acknowledgments</name> include" pn="section-appendix.c">
<t><contact fullname="Mark Nottingham"/> and <contact fullname="Erik Wilde <name slugifiedName="name-acknowledgments">Acknowledgments</name>
"/>, authors of RFC 7807. <contact fullname="Klaus Hartke"/> and <contact fulln <t indent="0" pn="section-appendix.c-1">The authors would like to thank <c
ame="Jaime Jiménez"/>, co-authors of an earlier generation of this ontact fullname="Mark Nottingham"/> and <contact fullname="Erik Wilde"/>, the au
specification. <contact fullname="Christian Amsüss"/>, <contact fullname="Marco thors of RFC 7807; <contact fullname="Klaus Hartke"/> and <contact fullname="Ja
Tiloca"/>, <contact fullname="Ari Keränen"/> ime Jiménez"/>, the coauthors of an earlier draft version of this
specification; <contact fullname="Christian Amsüss"/>, <contact fullname="Marco
Tiloca"/>, <contact fullname="Ari Keränen"/>,
and <contact fullname="Michael Richardson"/> for review and comments on this doc ument. and <contact fullname="Michael Richardson"/> for review and comments on this doc ument.
<contact fullname="Francesca Palombini"/> for her review (and support) as respon sible AD, <contact fullname="Francesca Palombini"/> for her review (and support) as respon sible AD,
and <contact fullname="Joel Jaeggli"/> for his OPSDIR review, both of which brou ght and <contact fullname="Joel Jaeggli"/> for his OPSDIR review, both of which brou ght
significant additional considerations to this document.</t> significant additional considerations to this document.</t>
<t>For <xref target="tag38"/>, <contact fullname="John Cowan"/> and <conta <t indent="0" pn="section-appendix.c-2">For <xref target="tag38" format="d
ct fullname="Doug Ewell"/> are also to be acknowledged. efault" sectionFormat="of" derivedContent="Appendix A"/>, <contact fullname="Joh
The content of an earlier version of this appendix was also discussed n Cowan"/> and <contact fullname="Doug Ewell"/> are also to be acknowledged.
in the "apps-discuss at ietf.org" and "ltru at ietf.org" mailing The content of an earlier draft version of this appendix was also discussed
in the "apps-discuss@ietf.org" and "ltru@ietf.org" mailing
lists. lists.
More recently, the authors initiated a discussion about the handling More recently, the authors initiated a discussion about the handling
of writing direction information in conjunction with language tags. of writing direction information in conjunction with language tags.
That led to discussions within the W3C Internationalization Core That led to discussions within the W3C Internationalization Core
Working Group. Working Group.
The authors would like to acknowledge that cross-organization The authors would like to acknowledge that cross-organization
cooperation and particular contributions from <contact fullname="John Klensin"/> and cooperation and particular contributions from <contact fullname="John Klensin"/> and
<contact fullname="Addison Phillips"/>, and specific text proposals by <contact <contact fullname="Addison Phillips"/> and specific text proposals by <contact f
fullname="Martin Dürst"/>.</t> ullname="Martin Dürst"/>.</t>
<!-- LocalWords: dereferencing dereferenced dereferenceable </section>
--> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.d">
</section> <name slugifiedName="name-contributors">Contributors</name>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse">
<name>Contributors</name>
<contact initials="P." surname="Occil" fullname="Peter Occil"> <contact initials="P." surname="Occil" fullname="Peter Occil">
<organization/> <organization showOnFrontPage="true"/>
<address> <address>
<email>poccil14 at gmail dot com</email> <email>poccil14@gmail.com</email>
<uri>http://peteroupc.github.io/CBOR/</uri> <uri>http://peteroupc.github.io/CBOR/</uri>
</address> </address>
</contact> </contact>
<t>Peter defined CBOR tag 38, basis of <xref target="tag38"/>.</t> <t indent="0" pn="section-appendix.d-1">Peter defined CBOR tag 38, basis o f <xref target="tag38" format="default" sectionFormat="of" derivedContent="Appen dix A"/>.</t>
<contact initials="C." surname="Amsüss" fullname="Christian Amsüss"> <contact initials="C." surname="Amsüss" fullname="Christian Amsüss">
<organization/> <organization showOnFrontPage="true"/>
<address> <address>
<email>christian@amsuess.com</email> <email>christian@amsuess.com</email>
</address> </address>
</contact> </contact>
<t>Christian contributed what became <xref target="uco"/>.</t> <t indent="0" pn="section-appendix.d-2">Christian contributed what became
<xref 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</organizatio
n>
<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> </section>
</back> </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> </rfc>
 End of changes. 261 change blocks. 
1274 lines changed or deleted 1395 lines changed or added

This html diff was produced by rfcdiff 1.48.