<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?> "rfc2629-xhtml.ent">

<rfc number="8710" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-core-multipart-ct-04" category="std"> consensus="true" category="std" obsoletes=""
     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
     tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Multipart Content-Format for CoAP">Multipart Content-Format
    for CoAP</title> the Constrained Application Protocol (CoAP)</title>

<seriesInfo name="RFC" value="8710"/>
    <author initials="T.F." initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>ARM</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <author initials="K." surname="Hartke" fullname="Klaus Hartke">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Torshamnsgatan 23</street>
          <city>Stockholm</city>
          <code>SE-16483</code>
          <code>16483</code>
          <country>Sweden</country>
        </postal>
        <email>klaus.hartke@ericsson.com</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2019" month="August" day="21"/> year="2020" month="February"/>
    <area>ART</area>
    <workgroup>CoRE</workgroup>
    <keyword>CoAP, Multipart
    <keyword>CoAP</keyword>
    <keyword>Multipart Content-Format</keyword>
    <abstract>
      <t>This memo defines application/multipart-core, an
      application-independent media-type media type that can be used to combine
      representations of zero or more different media types (each with a
      Constrained Application Protocol (CoAP) Content-Format identifier) into a single
message, such as a CoAP request or response body,
      representation, with minimal framing overhead, each along with a CoAP
Content-Format identifier.</t> overhead.
      </t>
    </abstract>
  </front>
  <middle>

    <section anchor="introduction" title="Introduction">

<t>This numbered="true" toc="default">
      <name>Introduction</name>
      <t>
This memo defines application/multipart-core, an application-independent
media-type media
type that can be used to combine representations of zero or more different
media types, each along types (each with a CoAP Content-Format
identifier, identifier <xref target="RFC7252"
format="default"/>) into a single representation, with minimal framing
overhead.
This combined representation may then be carried in a single message,
such as a CoAP <xref target="RFC7252"/> request or response body.</t>
</t>
      <t>This simple and efficient binary framing mechanism can be employed to
      create application specific request and response application-specific message bodies which that build on multiple
      already existing media types.</t>

      <t>As the name of the media-type media type suggests, it is application/multipart-core
      was inspired by the multipart media types that started to be initially defined with in the
      original set of MIME specifications <xref target="RFC2046"/>. target="RFC2046"
      format="default"/> and later.  However, while those needed to focus on the
      syntactic aspects of integrating multiple representations into one e-mail,
      email, transfer protocols providing full data transparency such as CoAP
      as well as readily available encoding formats such as the Concise Binary
      Object Representation (CBOR) <xref target="RFC7049"/> target="RFC7049" format="default"/>
      shift the focus towards the intended use of the combined
      representations.  In this respect, the basic intent of the
      application/multipart-core media type is like that of multipart/mixed (Section 5.1.3
      (<xref sectionFormat="of" section="5.1.3" target="RFC2046"
      format="default"/>); however, the semantics are relaxed to allow for
      both ordered and unordered collections of <xref target="RFC2046"/>). media types. </t>

      <ul empty="true">
<li>Historical Note: Experience with multipart/mixed in email has shown that
recipients that care about order of included body parts will process them in
the order they are listed inside multipart/mixed, and recipients that don't
care about the order will ignore it anyway.  The media type multipart/parallel
that was intended for unordered collections didn't deploy.
</li>
      </ul>
<t>
The detailed semantics of the representations are refined by the context
established by the application in the accompanying request parameters, e.g.,
the resource URI and any further options (header fields), but three usage
scenarios are envisioned:</t>

<t>The

      <t>In one case, the individual representations in an application/multipart-core message body
occur in a sequence, which may be employed by an application where
such a sequence is natural, e.g. e.g., for a number of audio snippets in
various formats to be played out in that sequence, sequence or search results
returned in order of relevance.</t>

      <t>In other cases, another case, an application may be more interested in a bag of
representations, which
      representations (which are distinguished by their Content-Format identifier,
      identifiers), such as an audio snippet and a text representation
      accompanying it.  In such a case, the sequence in which these occur may
      not be relevant to the application.  This specification adds the option
      of substituting a null value for the representation of an optional part,
      which indicates that the part is not present.</t>
      <t>A third situation that is common situation only ever has a single representation in the
      sequence, where and the sender already selects just one of a set of formats
      possible for this situation.  This kind of union “type” "type" of formats may
      also make the presence of the actual representation optional, the
      omission of which leads to a zero-length array.</t>

      <t>Where these rules are not sufficient for sufficient, an application, it application might still use
      the general format defined here, here but register a new media type and an
      associated Content-Format identifier to associate the representation
      with these more specific semantics instead of using the
      application/multipart-core media type.</t>
      <t>Also, future specifications might want to define rough equivalents
      for other multipart media types with specific semantics not covered by
      the present specification, such as multipart/alternative (Section 5.1.4 of
<xref (<xref
      sectionFormat="of" section="5.1.4" target="RFC2046"/>), where several
      alternative representations are provided in the message, message body, but only
      one of those is to be selected by the recipient for its use (this is
      less likely to be useful in a constrained environment that has
      facilities for pre-flight discovery).</t>
      <section anchor="requirements-language" title="Requirements Language">

<t>The numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="encoding" title="Multipart numbered="true" toc="default">
      <name>Multipart Content-Format Encoding"> Encoding</name>
      <t>A representation of media-type media type application/multipart-core contains a collection of
zero or more representations, each along with their respective content
format.</t> Content-Format.</t>
      <t>The collection is encoded as a CBOR <xref target="RFC7049"/> target="RFC7049"
      format="default"/> array with an even number of elements.  Counting from
      zero, the odd-numbered elements are a byte string containing a representation,
      representation or the value <spanx style="verb">null</spanx> if "null" (if an optional part is
      indicated as not given. given).  The (even-numbered) element preceding each of
      these is an unsigned integer specifying the content format Content-Format ID of the
      representation following it.</t>
      <t>For example, a collection containing two representations, one with
content format
Content-Format ID 42 and one with content format Content-Format ID 0, looks like this
in CBOR diagnostic notation:</t>

<t><list style='empty'>
  <t>[42, h’0123456789abcdef’,
<artwork><![CDATA[[42, h'0123456789abcdef', 0, h’3031323334’]</t>
</list></t> h'3031323334']]]>
</artwork>

      <t>For illustration, the structure of an application/multipart-core representation can
be described by the CDDL Concise Data Definition Language (CDDL) <xref target="RFC8610"/> target="RFC8610" format="default"/> specification in <xref target="mct-cddl"/>:</t> target="mct-cddl" format="default"/>:</t>
      <figure title="CDDL anchor="mct-cddl">
        <name>CDDL for application/multipart-core" anchor="mct-cddl"><artwork type="CDDL"><![CDATA[ application/multipart-core</name>
        <artwork type="cddl" name="" align="left" alt=""><![CDATA[
multipart-core = [* multipart-part]
multipart-part = (type: uint .size 2, part: bytes / null)
]]></artwork></figure>
]]></artwork>
      </figure>
      <t>This format is intended as a strict specification: An an implementation
MUST
<bcp14>MUST</bcp14> stop processing the representation if there is a CBOR
well-formedness error, a deviation from the structure defined above,
or any residual data left after processing the CBOR data item.
(This generally means the representation is not processed at
all except if unless some streaming processing has already happened.)</t>
    </section>
    <section anchor="usage-example-observing-resources" title="Usage numbered="true" toc="default">
      <name>Usage Example: Observing Resources"> Resources</name>
      <t>This section illustrates one a less obvious example for using
application/multipart-core: combining it with observing a resource
<xref target="RFC7641"/> target="RFC7641" format="default"/> to handle pending results.</t>

      <t>When a client registers to observe a resource for which no
      representation is available yet, the server may send one or more 2.05
      (Content) notifications before sending that indicate the lack of an actual
      representation. Later on, when one becomes available, the server will
      send the first actual 2.05 (Content) or 2.03 (Valid) notification.

A diagram depicting possible resulting sequences of notifications, identified
by their respective response code, is shown in <xref target="fig-sequence"/>.</t> target="fig-sequence"
format="default"/>.</t>
      <figure title="Sequence anchor="fig-sequence">
        <name>Sequence of Notifications" anchor="fig-sequence"><artwork><![CDATA[ Notifications</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
      __________       __________       __________
     |          |     |          |     |          |
---->|   2.05   |---->|  2.05 /  |---->|  4.xx /  |
     |  Pending |     |   2.03   |     |   5.xx   |
     |__________|     |__________|     |__________|
        ^   \ \          ^    \           ^
         \__/  \          \___/          /
                \_______________________/
]]></artwork></figure>
]]></artwork>
      </figure>
      <t>The specification of the Observe option requires that all
notifications carry the same Content-Format.  The
application/multipart-core media type can be used to provide that
Content-Format:
Content-Format, e.g., by carrying an empty list of representations in the
case marked as “Pending” "Pending" in <xref target="fig-sequence"/>, target="fig-sequence" format="default"/> and carrying a single
representation specified as the target content-format Content-Format in the case in
the middle of the figure.</t>
    </section>
    <section anchor="implementation-hints" title="Implementation Hints"> numbered="true" toc="default">
      <name>Implementation Hints</name>
      <t>This section describes the serialization for readers that may be new
to CBOR.  It does not contain any new information.</t>
      <t>An application/multipart-core representation carrying no
representations is represented by an empty CBOR array, which is
serialized as a single byte with the value 0x80.</t>
      <t>An application/multipart-core representation carrying a single
representation is represented by a two-element CBOR array, which is
serialized as 0x82 followed by the two elements.  The first element is
an unsigned integer for the Content-Format value, which is represented as described in
<xref target="tbl-integer"/>. target="tbl-integer" format="default"/>.  The second element is the object as a byte string,
which is represented as a length as described in <xref target="tbl-length"/> target="tbl-length" format="default"/>
followed by the bytes of the object.</t>

<texttable title="Serialization of content-format" anchor="tbl-integer">
      <ttcol align='left'>Serialization</ttcol>
      <ttcol align='left'>Value</ttcol>
      <c>0x00..0x17</c>
      <c>0..23</c>
      <c>0x18 0xnn</c>
      <c>24..255</c>
      <c>0x19
      <table anchor="tbl-integer" align="center">
        <name>Serialization of Content-Format</name>
        <thead>
          <tr>
            <th align="left">Serialization</th>
            <th align="left">Value</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0x00..0x17</td>
            <td align="left">0..23</td>
          </tr>
          <tr>
            <td align="left">0x18 0xnn</td>
            <td align="left">24..255</td>
          </tr>
          <tr>
            <td align="left">0x19 0xnn 0xnn</c>
      <c>256..65535</c>
</texttable>

<texttable title="Serialization 0xnn</td>
            <td align="left">256..65535</td>
          </tr>
        </tbody>
      </table>
      <table anchor="tbl-length" align="center">
        <name>Serialization of object length" anchor="tbl-length">
      <ttcol align='left'>Serialization</ttcol>
      <ttcol align='left'>Length</ttcol>
      <c>0x40..0x57</c>
      <c>0..23</c>
      <c>0x58 0xnn</c>
      <c>24..255</c>
      <c>0x59 Object Length</name>
        <thead>
          <tr>
            <th align="left">Serialization</th>
            <th align="left">Length</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0x40..0x57</td>
            <td align="left">0..23</td>
          </tr>
          <tr>
            <td align="left">0x58 0xnn</td>
            <td align="left">24..255</td>
          </tr>
          <tr>
            <td align="left">0x59 0xnn 0xnn</c>
      <c>256..65535</c>
      <c>0x5a 0xnn</td>
            <td align="left">256..65535</td>
          </tr>
          <tr>
            <td align="left">0x5a 0xnn 0xnn 0xnn 0xnn</c>
      <c>65536..4294967295</c>
      <c>0x5b 0xnn</td>
            <td align="left">65536..4294967295</td>
          </tr>
          <tr>
            <td align="left">0x5b 0xnn .. 0xnn (8 bytes)</c>
      <c>4294967296..</c>
</texttable> bytes)</td>
            <td align="left">4294967296..</td>
          </tr>
        </tbody>
      </table>
      <t>For example, a single text/plain object (content-format (Content-Format 0) of value
“Hello World”
"Hello World" (11 characters) would be serialized as</t>

<t><list style='empty'>
  <t>0x82 as follows:</t>
<artwork><![CDATA[0x82 0x00 0x4b H e l l o 0x20 W o r l d</t>
</list></t> d]]>
</artwork>

      <t>In effect, the serialization for a single object is done by prefixing
      the object with information that there is one object (here: 0x82),
      information about its content-format Content-Format (here: 0x00) 0x00), and information
      regarding its length (here: 0x4b).</t>

      <t>For more than one representation included in an
      application/multipart-core representation, the head of the CBOR array is
      adjusted (0x84 for two representations, 0x86 for three, …) etc.), and the
      sequences of content-format Content-Format and embedded representations follow.</t>
      <t>For instance, the example from <xref target="encoding"/> target="encoding"
      format="default"/> would be serialized as:</t>

<t><list style='empty'>
  <t>0x84 as follows:</t>
<artwork><![CDATA[0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x3031323334</t>
</list></t> 0x3031323334]]>
</artwork>

      <t>where (*) marks the start of the information about the first
      representation (content-format (Content-Format 42, byte string length 8) and, (+), 8), and (+) marks
      the start of the second representation (content-format (Content-Format 0, byte string
      length 5).</t>
    </section>

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="registration-of-media-type-applicationmultipart-core" title="Registration numbered="true" toc="default">
        <name>Registration of media type application/multipart-core"> Media Type application/multipart-core</name>
        <t>IANA is requested to register has registered the following media type <xref target="RFC6838"/>:</t>

<t><list style="hanging">
  <t hangText='Type name:'>
  application</t>
  <t hangText='Subtype name:'>
  multipart-core</t>
  <t hangText='Required parameters:'>
  N/A</t>
  <t hangText='Optional parameters:'>
  N/A</t>
  <t hangText='Encoding considerations:'>
  binary</t>
  <t hangText='Security considerations:'> target="RFC6838" format="default"/>:</t>
        <dl newline="false" spacing="normal">
          <dt>Type name:</dt>
          <dd>
  application</dd>
          <dt>Subtype name:</dt>
          <dd>
  multipart-core</dd>
          <dt>Required parameters:</dt>
          <dd>
  N/A</dd>
          <dt>Optional parameters:</dt>
          <dd>
  N/A</dd>
          <dt>Encoding considerations:</dt>
          <dd>
  binary</dd>
          <dt>Security considerations:</dt>
          <dd>
  See the Security Considerations Section section of RFCthis</t>
  <t hangText='Interoperability considerations:'>
  N/A</t>
  <t hangText='Published specification:'>
  RFCthis</t>
  <t hangText='Applications RFC 8710.</dd>
          <dt>Interoperability considerations:</dt>
          <dd>
  N/A</dd>
          <dt>Published specification:</dt>
          <dd>
  RFC 8710</dd>
          <dt>Applications that use this media type:'> type:</dt>
          <dd>
  Applications that need to combine representations of zero or more different
media types into one, e.g., EST-CoAP EST over secure CoAP (EST-CoAP) <xref target="I-D.ietf-ace-coap-est"/></t>
  <t hangText='Fragment target="I-D.ietf-ace-coap-est" format="default"/></dd>
          <dt>Fragment identifier considerations:'> considerations:</dt>
          <dd>
  The syntax and semantics of fragment identifiers specified for
“application/multipart-core” is
  application/multipart-core are as specified for “application/cbor”. application/cbor. (At
  publication of this document, there is no fragment identification syntax
  defined for “application/cbor”.)</t>
  <t hangText='Additional information:'>
        <list style="hanging">
        <t hangText='Deprecated application/cbor.)</dd>
          <dt>Additional information:</dt>
          <dd>
            <ul>
              <li>Deprecated alias names for this type:'>
        N/A</t>
        <t hangText='Magic number(s):'>
        N/A</t>
        <t hangText='File extension(s):'>
        N/A</t>
        <t hangText='Macintosh type: N/A</li>
              <li>Magic number(s): N/A</li>
              <li>File extension(s): N/A</li>
              <li>Macintosh file type code(s):'>
        N/A</t>
      </list>
  </t>
  <t hangText='Person code(s):N/A</li>
            </ul>
          </dd>
          <dt>Person &amp; email address to contact for further information:'>
  iesg&amp;ietf.org</t>
  <t hangText='Intended usage:'>
  COMMON</t>
  <t hangText='Restrictions information:</dt>
          <dd>
  iesg@ietf.org</dd>
          <dt>Intended usage:</dt>
          <dd>
  COMMON</dd>
          <dt>Restrictions on usage:'>
  N/A</t>
  <t hangText='Author:'> usage:</dt>
          <dd>
  N/A</dd>
          <dt>Author:</dt>
          <dd>
  CoRE WG</t>
  <t hangText='Change controller:'>
  IESG</t>
  <t hangText='Provisional WG</dd>
          <dt>Change controller:</dt>
          <dd>
  IESG</dd>
          <dt>Provisional registration? (standards tree only):'>
  no</t>
</list></t> only):</dt>
          <dd>
  no</dd>
        </dl>
      </section>
      <section anchor="registration-of-a-content-format-identifier-for-applicationmultipart-core" title="Registration numbered="true" toc="default">
        <name>Registration of a Content-Format identifier Identifier for application/multipart-core"> application/multipart-core</name>
        <t>IANA is requested to register has registered the following Content-Format to in the
“CoAP Content-Formats” subregistry, "CoAP
        Content-Formats" subregistry within the “Constrained "Constrained RESTful
        Environments (CoRE) Parameters” registry, from the Expert Review space
(0..255):</t>

<texttable>
      <ttcol align='left'>Media Type</ttcol>
      <ttcol align='left'>Encoding</ttcol>
      <ttcol align='left'>ID</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>application/multipart-core</c>
      <c>—</c>
      <c>TBD1</c>
      <c>RFCthis</c>
</texttable> Parameters" registry:</t>
        <table align="center">
        <name>Addition to "CoAP Content-Formats" Registry</name>
          <thead>
            <tr>
              <th align="left">Media Type</th>
              <th align="left">Encoding</th>
              <th align="left">ID</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">application/multipart-core</td>
              <td align="left">-</td>
              <td align="left">62</td>
              <td align="left">RFC 8710</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

<t>The security considerations of <xref target="RFC7049"/> target="RFC7049" format="default"/>
apply.  In particular, resource exhaustion attacks may employ large values for
the byte string size fields, fields or employ deeply nested structures of recursively
embedded application/multipart-core representations.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference  anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date year='2013' month='October' />
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.  These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>

<reference  anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

    </references>

    <references title='Informative References'>

<reference  anchor="RFC2046" target='https://www.rfc-editor.org/info/rfc2046'>
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'><organization /></author>
<date year='1996' month='November' />
<abstract><t>This second document defines the general structure of the MIME media typing system and defines an initial set of media types.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2046'/>
<seriesInfo name='DOI' value='10.17487/RFC2046'/>
</reference>

<reference  anchor="RFC7641" target='https://www.rfc-editor.org/info/rfc7641'>
<front>
<title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='RFC' value='7641'/>
<seriesInfo name='DOI' value='10.17487/RFC7641'/>
</reference>

<reference anchor="I-D.ietf-ace-coap-est">
<front>
<title>EST over secure CoAP (EST-coaps)</title>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='P' surname='Kampanakis' fullname='Panos Kampanakis'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='S' surname='Raza' fullname='Shahid Raza'>
    <organization />
</author>

<date month='June' day='5' year='2019' />

<abstract><t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS.  Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges.  This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ace-coap-est-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ace-coap-est-12.txt' />
</reference>

<reference  anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'>
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization /></author>
<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2019' month='June' />
<abstract><t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8610'/>
<seriesInfo name='DOI' value='10.17487/RFC8610'/>
</reference>

<reference  anchor="RFC6838" target='https://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>

    </references>

<section numbered="no" anchor="acknowledgements" title="Acknowledgements">

<t>Most of

<displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-ace-coap-est.xml"/>

      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" toc="default">

      <name>Acknowledgements</name>
      <t>Most of the text in this draft document is from earlier contributions by
      two of the authors, Thomas Fossati <contact fullname="Thomas Fossati"/> and Klaus Hartke.  The re-mix <contact
      fullname="Klaus Hartke"/>.  This earlier work was reorganized in this document is based on the
      requirements in <xref target="I-D.ietf-ace-coap-est"/>, based on target="I-D.ietf-ace-coap-est" format="default"/>
      and discussions with Michael Richardson, Panos Kampanis <contact fullname="Michael Richardson"/>,
      <contact fullname="Panos Kampanis"/>, and Peter <contact fullname="Peter van
      der
Stok.</t>

<!--  LocalWords:  multipart
 --> Stok"/>.</t>

    </section>
  </back>

<!-- ##markdown-source:
H4sIAKKYXV0AA51bbVcbyZX+Xr+igs+JIZFkIQQGnZ3JYMAxJ8awgDNnN5NM
St0lqUKrS+nqBjSY+S35kF+y+8f2ubeqW90twDMr26Curpdb9+W5L1XudrvC
5SqNf1SJTfVI5lmhhVlk/M3lg37/oD8QsY1SNcfrOFOTvGt0PulGNtPdeZHk
ZqGyvBvl3UTl2uUiUvlIujwWCzMSEt8yE6Hl9VK713jObdR4iPUin6FlSM9u
Oc/0xK06OJvlzZbIzheqPqErxqu21IY+c53mtVEmTQztzz/nJk/wcFZSL49s
mmNA973N5iqXE5uh6fBCqPE407e/qGem1UgeXl6Lu+kITZcn4uZuxO86zw4X
r2QMpo3koL990O3vdwfbQhX5zGYj0QXN2MB1T77HX+ucyg024uVwPbNz5WrN
NpvS6mf4qufKJJAfd+lNfJfvVDbvgS2iW83xp0QVTn4AVTe6nOEEsnLOpqtp
bqhXb8a9vtPhNc/EotUaXL+2mZupeeqmCrokBzskApMvR/IKAr6Z2WTOQomx
6tVJd3tvuM9dbJHmGfW607FOmTTe81FPviP+pGlF7JHKHBhXa2d6P6fmVmfO
5P/771y+yzSkLq//+7RG24V1+URFM7mz0x8O+xVlvnNF1nF3sL+ze1Cn6o+a
llqiaTFj2/j98KA7HGxDSPvdvZ0DyKriUqTG9rv8J9MDVUKkLFxQRvp/+f7o
bX94gD5jm4Xnwe4Az1YthEknrc6D/nBvJOdmrrv5cqFdGLI33B5JO3Y6uyVp
nXaPe2yGKtJdmqkL0xtJ/OAnP2h/b7uPdeI4EaLb7Uo1BldgJ0Jcz4yTcz23
MtYTGIaTarFIDEzX2PRNzaph5B2pUlF73TUpbFbjR5pjjtgoJhQKB3uIIP+x
loXTscgtGeIY08tMLzLtMIBncNJO5E86sxCinGMJGZvJRGfVhJJ3DmXAFEo6
k04TLeYamjwFOa6AOKH9iq0Lc/+zwL5pLqyxwPRajm287Mg7k8/AydTMVSIn
mcLXqbRQmJlWcUdqUgvCvanv6ecTLQs3tE8zMTrreS7ODRiqBWz3FIpi4yKi
Pf16nspneCpe4Kn85TwVT/L0uV23gWm1605TDK1lv8LknudKIDluDZZztcQW
NW8vUllm0MWkq7VKkYuWyB8eWMsfH58Vfi/Iw5n5AhPBw0k9mZjIED9Ai8qW
FbFzHc1Uaty85LTGGLtkbosIuJ7ruqykW+gIrImqxWn2+uoGsr+bGZA8LkwS
S2iHFz9RkmDCeCn1vXG5X70SDog+dMQQBj0SKH2vqYMrplMsCCkaKCYZiFuY
DISOmY+iUrKGGbESwctnuVcg7NBraOyFR4vYzEzBlUQ6nQssfHZ6dlJtNCgY
uL6CpcfHnpQf7J2+JRXBbhPSVgsGpBpoztY/sRE8DDhGK7glpA5TiSBHzJuz
wkK19DRTnhGBRaKt2Kx/QGCJeANo20FoolIH3ZaLzMLB2MTRt1sT0zSTIknI
qyrB3cANnUbLCjRYf/D7TqMbfpM0TLKU6hZTqzF2ge6WZhIemV01lHYBM4kM
NvnOq9D5+B/YirxsqvXm0bvzyy1BWgrMh5a6mZnkPN6zJLd3Kov9jMSClBgG
+y5F/oy9OLD8lLhpHOsblu5w/7FyJhI8U17O8Tz41JSDlCgxNwFo7GSlQW/m
5h4EbF5phje529vu7dDcLS3YAk3XM9KoHAzENhxcIqAjciUhbXFCIGjz+uf1
FvsF6fe5gG5DBMbNVq/qhme8JqmI4710SeIubRA0w2ZyBAMdoXvTXies7WyR
RVp+vjxlM8UoaEiGd5m0C0/QJiEVnoF2Sey2OrDaXOQzxA/AXMCPdJGGtI31
tOv01jgM1PGIQIYkGBsoXwHrWVfdFtC3RUFYJWwUFVkAPtpOGulOABBCyDoi
gSvNCdEPIB8AshpOck1VXmQK5kLs4EBVybSYj2nnE6mK2FjpUrNY6JwIFbe0
RShnqfYeKRaJonVtkXv2E5RUNGJOp1WGpbFrbMzBdrFo6mHcZrFfK9OJvlUY
AYCD/lrmfqQcuaPWbsJ+OSggfca8eekUxmpKKtricckpxWEEY2pR1yCTtWP2
mm9bOZa0yRGvLJK0su20Gupn8h5tKbCf9uQVbyWINNCHVjJwFjXtMrU57TTw
Jie8bOl7cJ4NFJYqDrjhtZcYggQI284LRlGSMZDtViWFZqGvmyCLPw0TQGlJ
GzvCU0m6HFEe50VNg9mfkD6B4DANOSqCoSyGg80LPysP8M5+ToukQFXyDnLG
jvvJ8EEEk66rPWQe2lLSn9JhOjCKvMY/CnL3KWMlKTwDXtBZsUC2YwjE/c45
AAj0MU6h4QZbpCFFSkRvEIxt1KYg2QiVOIsvN54QT3BUoTO82LqtV+xk+Qs7
N84FXnvOJtgFG5XiMK2b6HRK4VeWKYpWvi/3DSXJikR7rCGeu6IKXNiIGwbD
kcDcTGc58ngDwZMXISKnOtUZRWRe50uHT6swwIH8KaxFMyroO+8TBPsEj5Ow
Cmcjo8j8njUg3k/Zjzfe4koZYLhg01XstHITCGJy8IZlQkoifrH3IjWEpDpA
dKCObscrzBZ5h2WITM8BmdliOpNQNwMToRoBcUh4SHo6fOItPEE3ySaiQHcV
f4WtNwlZJSwr56oScD7ltK/pYodk0G0XW1qFI3OCTOujn/CuwgdDHjZ9BBky
J5I722WwHx+wmRLrvYnxdoSHjcgsKsUz4BVp1ybbFQUOmJajB0zoJ8BrhF+M
1gI+nbJN1jpymZlNqSbjYYIgAVm5SUxOwTJNj210JwmLDDDOjF1uQcKvXiG8
grg4XwcJHxUAHrvxvvdGL+WdpVhq4+zz1fVGx/+Wn875++XJf34+vTw5pu9X
Hw4/fqy+iNDj6sP554/Hq2+rkUfnZ2cnn479YLTKRpPYODv8r40OG8vG+cX1
6fmnw48bnuPgTYw4j7dLVuyZw+4MuyQGKydi7aLMjL2U3h1d/M+/tocIrn5D
JYDt7QNEjf5hf/vtEA/QgNSvxgL0jxDSklJz+GBmOuw/UguTA786pHBuZu9S
tnkwEgnrs2WskxDzyodXZfj7SBi/7jhq2cgLNkoBHURPuI/wPAkKDtVuZP1r
nrydm3r3HUJd0vbIkx1C857XgdoK4DzTzyymbBGBuFzF4Qy2Ie1NyTmlYhUR
QflZw3riiEpAnEtkds5o7Z26jeOu7086HbqzhBGcLAGAVOvEsLB7wjK1li8H
l+wd9N/JWf9dmnWH7NM774xjoTzcTMEDDgtghUR9Rc1WSQ6ZUaRZlMxM77K8
kWOJInVm6sMzJF46Ex6pOJSpAnFv76QWp8dPB/F4nyT2rgyABLQICa2iVLvT
FPmKFTK/s+sSJyAieYj1lYeDoO6+xxO09TsysfamSmGMo3iCZQ4lnabWUboJ
xvFqiNa/lT/8ZTjoyNnr/vZgZ7i793b/QI0juIbXHZpt9nqnv7O9M9jZ2Rm+
/qvfF5xqQUDmpceBSZ4VETscH0i9YActtkUqFZx9l6Yfkpyj4+OPrKZxnFC6
2Ij4sKWHh3mUh7fYxs8//0wjRGuxb+RffrfyMV368VfRfEafTbLdkSygAbLn
zE9agiH0bsQ67OQbjiC3aBXxMHpVriy5aP7NBtPKgciz2954DNWXICpWZZ/l
erP0ZwLNfY7kIfZKKjSvokOGcpfbBeX3EdxNqactvhpW0sxrOSuAoPy+S+vr
OCU/pbPMZqScsb41QYnJupsCLcMkNYb/6QgOt5YEQD69o7IC3B5yeTXJff2h
TpXXPOpjcj3viU1mQojEANpzrVL3JP1ldM3T0fq5IDDX95Fe5LQ9Z+dMp/Yl
q9rCHF2HGHlGvgD097YI7T9z8nri7XIkz7l4TEMuQ1bsyiJZiZ6lqmvHZscO
3o5vOS0M9s2i93Ha8wowChUMDxDefG21vKrScop0Qk0bag83OYPFYw2qhPrk
nrNKHx5TChglHI6UsSsHLmGC2rRMo4+6U9uOSElFqlrPUudlvpZRqkKJGeUd
PkAKbmrQ6++KzeAxt0hStSBzrCcc1waKucZjMioK+iyhNRhzomVHbv5ZJSZu
ToYM5ZCBK1NzaOICJsKyDjmN8NygpjJd4hpLg57OKjivJcArDyqqOiV5yQ5x
wwcJjDITM+2Wcz8+gu2y+vxYfb7esBr2Rba+vtjA47r4fEutxDlqLRv4+U2t
Ydi7v+eGxnoXQRKr6Znh9fV2aWBz3Ir4L19vqLFFyr/h3w/402ioP8u/NfrL
H3788U2jAxqopfy8aXavdXrq8wYYLV/VBVcC9VX5DB35VNcRD8+tdKl09OfB
mkJ5IfOhdygHAJNEU/2pau99mKOSdTOs9KXBF3CiXolsnXKEHIbXbR3JjKQv
8PHaDCgpFcjyJeIAl/uC01oZjtIzKs/AxLMb74c2gqpsPKX8PtZeLVGeQrXQ
JPDQT0hsyFU21XkZrHRLD+gTMSbApJxc+WOkku1YvOAo/ZU8bfhA+QGusw3U
ZQDhSuwyQJOfytAs46I2oyMJLZTUkORTjYl8FJWRkWVZXSaxHKOxq6NSQHUm
SSUocfjrApzArzXc5YyxaqoqmV5u7Dg5OC+reQjlym1VQYMvIHGgXZ1b+DC6
f7/f/3+T+pxon6CXYthuGWn/AqJB1yDEyqtgj+LgKtfwxXPvMcqJMc0ToXpV
zGulbsyBFQUNmkFCPc2Eu83HSTdMyCc4jAMaGhDXlvfJjj/aYNbXkpuqULi2
EkVGvqTVXFX6Vf3Lx0fR5oePOoMd+FUhyy/yqqHWpaP4Mwv8C9737/v9Xq9/
v/227kjQNNgJ77f38SNN5er9YIjXu7vl+wP/nn98kYPdvV5vb3d3h94TqtaY
tQLVOlEgumnoBK3PUP7RM8evPGTKd5+lfPcrlO++QDm/V7X39Z7UCX2Hg4Ph
wd7bwcGuLEeMfZdez//e3PeC2aL1q+4YWuNNkPdzrAka5HsRZ1ppYjBoqrG/
WSSEQGHEZgs9+1s0HSu62PiAwN7K722WxBtyc3tbRjNFlxqAd1vyzhZJ7EtZ
NTukxI9NkVSGuD+WHyTCW/yxeBz05ff4kuEx5gMKPZlUR2vr4FoRHqjlak9K
ekzJ98TclzXM8J6xqoapVWXd5yscaYZ9U9uISd3qCOQgdOiSu7Yzqbr1wRjy
UtQnyKJ6NxxvhcScY1ismfJSbZBLo6QIpcLmNY+X4dMzZxbqtlXyw3AoKMSO
qU5PB4jYzdBj11P5P97uBWTLNLSi1+vxnkT9VMCtG5o/0Z8DYeL1Y9IAuWH/
VF9WfLZAc1ZpDCV/Dw9VtevxGd0ZBeUZys3fbTGmDA6JvWSgqyLC4buj45P3
cvP3W5WO7eLHqpoghC/h0iQUgQTPTYfyJQPrKuJlXyUTbdfUNhCqadQLUEEZ
9pmVHSKrQ8W3fAX2X5mw/+R8u1u+jHh6+OmQ3BCyYp2VlwNeUetjqNdSepY1
a4byKzVDWB5Ny36Fj3R9HFgdU/jT87LsVJvy4eEPl++P9vZ39rk4ck1tfGlM
jOrLCXFVjPP6y/b6ocwc186SqdunN4dCnNdqc+13VfE0arCE3vubJlhaR0Vm
EOmsd7nS/sCm6tJi7FVVPKUrXVzkAkaBALtAnzGV0J+alim7KMrT9GapBe+r
uQ5XLAoBoz9C4stMJZNpxHpHuunxK24krW55IcNZu+cFcOqEwP7k6rpb3vMp
b7Q9kv/I1NSHKKsDqPWdX5eXTe4ZJBr3ESbrM7haDD/hG3obL1S2uHzQGtIc
QKXmjR6m2TzM5YIEUE+wakcDnZUPSG1FGd2BDLSV1438XsrS1DMLbkGScWyC
ltawhFhCn2MSDleTkcYZKihDj93qoNSL2UccQX38w5maUhWVK82bbuvJPu/p
+g/8uE7p0PO5XmcqIlG7GVCNHD+nfTbW6/0vIBds/bf+fiUdemdUi2Jd42tE
THd5kaO1W6Pd9Ld0OdLfxjwtS498mYM60DHO+ScyeF+I9MqarjowDYfhIq6/
zSu//6MQR/CiU18lz6jGzW9PT67w6oLyVee5n9Xw7w9yky9Y+/s+dKeEzm+2
aCBypCfhUr1w3vpy4fXXYWhrFX8BQWw8cR3QbdAt67CtcLEypLQbR7VzvktY
7qRIgIjVeZ+Tm8S+LXlRAeeGXM1U1WBP7gFndJPq1iAFdQsVabHZ55gXzBIc
Bp8xZjDAtz9fVkdYX+hogFouNaNNpH2l58tLyeEXqjuVU12/O96m8R4iqYm8
3nMA/fCqfFPWVZ4G+3B5qjyKAi1Lf5+LqDBRkaisI6oSpr6fKURQHAzk0Pgb
vpkQLgLJhKoMPiJ2VWJY89iCC/v+QhMfOcVaYz0gNutEVfB2vloCep25pXPc
MqT65ZGgC9dix6CRo4PD6Ca1d4mOpz7HpXShPKf6hi7og01n1lVxD9+xqc5N
6T8YkAKzYmiVJQHksa1xEUquS44lQ0Dj78tjl8078Yz99SvuIdml/7Rg7sv1
RHVOiyXHimpP4bpiVj9z5iS25oo6VV9BZ9UFX/UINwXOkB0rnchL+g2jp1j5
QqXWyT8pujbEB3GxvCBTgASpmJOJq9zeUGz1H78hLfxoI5V8T6fagO6K+QIq
+q34P3zw5yeyMQAA

-->

</rfc>