rfc8710xml2.original.xml   rfc8710.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc strict="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-core-multipart-ct-04" category="std"> <rfc number="8710" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-core-multipart-ct-04" consensus="true" category="std" o
bsoletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="Multipart Content-Format for CoAP">Multipart Content-Format f <title abbrev="Multipart Content-Format for CoAP">Multipart Content-Format
or CoAP</title> for the Constrained Application Protocol (CoAP)</title>
<author initials="T.F." surname="Fossati" fullname="Thomas Fossati"> <seriesInfo name="RFC" value="8710"/>
<author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>ARM</organization> <organization>ARM</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
<author initials="K." surname="Hartke" fullname="Klaus Hartke"> <author initials="K." surname="Hartke" fullname="Klaus Hartke">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Torshamnsgatan 23</street> <street>Torshamnsgatan 23</street>
<city>Stockholm</city> <city>Stockholm</city>
<code>SE-16483</code> <code>16483</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>klaus.hartke@ericsson.com</email> <email>klaus.hartke@ericsson.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>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="2020" month="February"/>
<date year="2019" month="August" day="21"/>
<area>ART</area> <area>ART</area>
<workgroup>CoRE</workgroup> <workgroup>CoRE</workgroup>
<keyword>CoAP, Multipart Content-Format</keyword> <keyword>CoAP</keyword>
<keyword>Multipart Content-Format</keyword>
<abstract> <abstract>
<t>This memo defines application/multipart-core, an
<t>This memo defines application/multipart-core, an application-independent media type that can be used to combine
application-independent media-type that can be used representations of zero or more different media types (each with a
to combine representations of zero or more different media types into a single Constrained Application Protocol (CoAP) Content-Format identifier) into a
message, such as a CoAP request or response body, with minimal framing overhead, single
each along with a CoAP representation, with minimal framing overhead.
Content-Format identifier.</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>This memo defines application/multipart-core, an application-independent <t>
media-type that can be used to combine representations of zero or more This memo defines application/multipart-core, an application-independent media
different media types, each along with a CoAP Content-Format type that can be used to combine representations of zero or more different
identifier, into a single representation, with minimal framing overhead. media types (each with a CoAP Content-Format identifier <xref target="RFC7252"
This combined representation may then be carried in a single message, format="default"/>) into a single representation, with minimal framing
such as a CoAP <xref target="RFC7252"/> request or response body.</t> overhead.
</t>
<t>This simple and efficient binary framing mechanism can be employed to
create application-specific message bodies that build on multiple
already existing media types.</t>
<t>This simple and efficient binary framing mechanism can be employed to <t>As the name of the media type suggests, application/multipart-core
create application specific request and response bodies which build on was inspired by the multipart media types initially defined in the
multiple already existing media types.</t> original set of MIME specifications <xref target="RFC2046"
format="default"/> and later. However, while those needed to focus on the
syntactic aspects of integrating multiple representations into one
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" 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
(<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 media types. </t>
<t>As the name of the media-type suggests, it is inspired by the <ul empty="true">
multipart media types that started to be defined with the original set <li>Historical Note: Experience with multipart/mixed in email has shown that
of MIME specifications <xref target="RFC2046"/>. However, while those needed recipients that care about order of included body parts will process them in
to focus on the syntactic aspects of integrating multiple the order they are listed inside multipart/mixed, and recipients that don't
representations into one e-mail, transfer protocols providing full data care about the order will ignore it anyway. The media type multipart/parallel
transparency such as CoAP as well as readily available encoding that was intended for unordered collections didn't deploy.
formats such as the Concise Binary Object Representation (CBOR) </li>
<xref target="RFC7049"/> shift the focus towards the intended </ul>
use of the combined representations. In this respect, the basic <t>
intent of the application/multipart-core media type is like that of The detailed semantics of the representations are refined by the context
multipart/mixed (Section 5.1.3 of <xref target="RFC2046"/>). The detailed established by the application in the accompanying request parameters, e.g.,
semantics of the representations are refined by the context the resource URI and any further options (header fields), but three usage
established by the application in the accompanying request parameters, scenarios are envisioned:</t>
e.g., the resource URI and any further options (header fields), but
three usage scenarios are envisioned:</t>
<t>The individual representations in an application/multipart-core body <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 occur in a sequence, which may be employed by an application where
such a sequence is natural, e.g. for a number of audio snippets in such a sequence is natural, e.g., for a number of audio snippets in
various formats to be played out in that sequence, or search results various formats to be played out in that sequence or search results
returned in order of relevance.</t> returned in order of relevance.</t>
<t>In other cases, an application may be more interested in a bag of <t>In another case, an application may be more interested in a bag of
representations, which are distinguished by their Content-Format identifier, representations (which are distinguished by their Content-Format
such as an audio snippet and a text representation accompanying it. identifiers), such as an audio snippet and a text representation
In such a case, the sequence in which these occur may not be relevant accompanying it. In such a case, the sequence in which these occur may
to the application. not be relevant to the application. This specification adds the option
This specification adds the option of of substituting a null value for the representation of an optional part,
substituting a null value for the representation of an optional part, which indicates that the part is not present.</t>
which indicates that the part is not present.</t> <t>A third common situation only has a single representation in the
sequence, and the sender selects just one of a set of formats
<t>A third situation that is common only ever has a single representation possible for this situation. This kind of union "type" of formats may
in the sequence, where the sender already selects just one of a set of formats also make the presence of the actual representation optional, the
possible for this situation. This kind of union “type” of formats may omission of which leads to a zero-length array.</t>
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 an application, it might
still use the general format defined 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 target="RFC2046"/>), where several alternative representations are
provided in the message, 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 key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
</section>
</section>
<section anchor="encoding" title="Multipart Content-Format Encoding">
<t>A representation of media-type application/multipart-core contains a collecti <t>Where these rules are not sufficient, an application might still use
on of the general format defined here but register a new media type and an
zero or more representations, each along with their respective content associated Content-Format identifier to associate the representation
format.</t> 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 (<xref
sectionFormat="of" section="5.1.4" target="RFC2046"/>), where several
alternative representations are provided in the 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" numbered="true" toc="default">
<name>Requirements Language</name>
<t>The collection is encoded as a CBOR <xref target="RFC7049"/> array with an ev <t>
en The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
number of elements. "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
Counting from zero, the odd-numbered elements are a byte string containing NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
a representation, or the value <spanx style="verb">null</spanx> if an optional p "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
art is indicated "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
as not given. to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
The (even-numbered) element preceding each of these is an unsigned integer <xref target="RFC8174"/> when, and only when, they appear in all capitals,
specifying the content format ID of the representation following it.</t> as shown here.
</t>
<t>For example, a collection containing two representations, one with </section>
content format ID 42 and one with content format ID 0, looks like this </section>
<section anchor="encoding" numbered="true" toc="default">
<name>Multipart Content-Format Encoding</name>
<t>A representation of media type application/multipart-core contains a co
llection of
zero or more representations, each along with their respective Content-Format.</
t>
<t>The collection is encoded as a CBOR <xref 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 or the value "null" (if an optional part is
indicated as not given). The (even-numbered) element preceding each of
these is an unsigned integer specifying the Content-Format ID of the
representation following it.</t>
<t>For example, a collection containing two representations, one with
Content-Format ID 42 and one with Content-Format ID 0, looks like this
in CBOR diagnostic notation:</t> in CBOR diagnostic notation:</t>
<artwork><![CDATA[[42, h'0123456789abcdef', 0, h'3031323334']]]>
</artwork>
<t><list style='empty'> <t>For illustration, the structure of an application/multipart-core repres
<t>[42, h’0123456789abcdef’, 0, h’3031323334’]</t> entation can
</list></t> be described by the Concise Data Definition Language (CDDL) <xref target="RFC861
0" format="default"/> specification in <xref target="mct-cddl" format="default"/
<t>For illustration, the structure of an application/multipart-core representati >:</t>
on can <figure anchor="mct-cddl">
be described by the CDDL <xref target="RFC8610"/> specification in <xref target= <name>CDDL for application/multipart-core</name>
"mct-cddl"/>:</t> <artwork type="cddl" name="" align="left" alt=""><![CDATA[
<figure title="CDDL for application/multipart-core" anchor="mct-cddl"><artwork t
ype="CDDL"><![CDATA[
multipart-core = [* multipart-part] multipart-core = [* multipart-part]
multipart-part = (type: uint .size 2, part: bytes / null) multipart-part = (type: uint .size 2, part: bytes / null)
]]></artwork></figure> ]]></artwork>
</figure>
<t>This format is intended as a strict specification: An implementation <t>This format is intended as a strict specification: an implementation
MUST stop processing the representation if there is a CBOR <bcp14>MUST</bcp14> stop processing the representation if there is a CBOR
well-formedness error, a deviation from the structure defined above, well-formedness error, a deviation from the structure defined above,
or any residual data left after processing the CBOR data item. or any residual data left after processing the CBOR data item.
(This generally means the representation is not processed at (This generally means the representation is not processed at
all except if some streaming processing has already happened.)</t> all unless some streaming processing has already happened.)</t>
</section>
</section> <section anchor="usage-example-observing-resources" numbered="true" toc="def
<section anchor="usage-example-observing-resources" title="Usage Example: Observ ault">
ing Resources"> <name>Usage Example: Observing Resources</name>
<t>This section illustrates a less obvious example for using
<t>This section illustrates one less obvious example for using
application/multipart-core: combining it with observing a resource application/multipart-core: combining it with observing a resource
<xref target="RFC7641"/> to handle pending results.</t> <xref target="RFC7641" format="default"/> to handle pending results.</t>
<t>When a client registers to observe a resource for which no <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 representation is available yet, the server may send one or more 2.05
(Content) notifications before sending the first actual 2.05 (Content) notifications that indicate the lack of an actual
(Content) or 2.03 (Valid) notification. A diagram depicting possible representation. Later on, when one becomes available, the server will
resulting sequences of notifications, identified by their respective send the first actual 2.05 (Content) or 2.03 (Valid) notification.
response code, is shown in <xref target="fig-sequence"/>.</t>
<figure title="Sequence of Notifications" anchor="fig-sequence"><artwork><![CDAT A diagram depicting possible resulting sequences of notifications, identified
A[ by their respective response code, is shown in <xref target="fig-sequence"
format="default"/>.</t>
<figure anchor="fig-sequence">
<name>Sequence of Notifications</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
__________ __________ __________ __________ __________ __________
| | | | | | | | | | | |
---->| 2.05 |---->| 2.05 / |---->| 4.xx / | ---->| 2.05 |---->| 2.05 / |---->| 4.xx / |
| Pending | | 2.03 | | 5.xx | | Pending | | 2.03 | | 5.xx |
|__________| |__________| |__________| |__________| |__________| |__________|
^ \ \ ^ \ ^ ^ \ \ ^ \ ^
\__/ \ \___/ / \__/ \ \___/ /
\_______________________/ \_______________________/
]]></artwork></figure> ]]></artwork>
</figure>
<t>The specification of the Observe option requires that all <t>The specification of the Observe option requires that all
notifications carry the same Content-Format. The notifications carry the same Content-Format. The
application/multipart-core media type can be used to provide that application/multipart-core media type can be used to provide that
Content-Format: e.g., carrying an empty list of representations in the Content-Format, e.g., by carrying an empty list of representations in the
case marked as “Pending” in <xref target="fig-sequence"/>, and carrying a single case marked as "Pending" in <xref target="fig-sequence" format="default"/> and c
representation specified as the target content-format in the case in arrying a single
representation specified as the target Content-Format in the case in
the middle of the figure.</t> the middle of the figure.</t>
</section>
</section> <section anchor="implementation-hints" numbered="true" toc="default">
<section anchor="implementation-hints" title="Implementation Hints"> <name>Implementation Hints</name>
<t>This section describes the serialization for readers that may be new
<t>This section describes the serialization for readers that may be new
to CBOR. It does not contain any new information.</t> to CBOR. It does not contain any new information.</t>
<t>An application/multipart-core representation carrying no
<t>An application/multipart-core representation carrying no
representations is represented by an empty CBOR array, which is representations is represented by an empty CBOR array, which is
serialized as a single byte with the value 0x80.</t> serialized as a single byte with the value 0x80.</t>
<t>An application/multipart-core representation carrying a single
<t>An application/multipart-core representation carrying a single
representation is represented by a two-element CBOR array, which is representation is represented by a two-element CBOR array, which is
serialized as 0x82 followed by the two elements. The first element 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 descri bed in an unsigned integer for the Content-Format value, which is represented as descri bed in
<xref target="tbl-integer"/>. The second element is the object as a byte string <xref 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"/> which is represented as a length as described in <xref target="tbl-length" forma
t="default"/>
followed by the bytes of the object.</t> followed by the bytes of the object.</t>
<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</td>
<td align="left">256..65535</td>
</tr>
</tbody>
</table>
<table anchor="tbl-length" align="center">
<name>Serialization of 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</td>
<td align="left">256..65535</td>
</tr>
<tr>
<td align="left">0x5a 0xnn 0xnn 0xnn 0xnn</td>
<td align="left">65536..4294967295</td>
</tr>
<tr>
<td align="left">0x5b 0xnn .. 0xnn (8 bytes)</td>
<td align="left">4294967296..</td>
</tr>
</tbody>
</table>
<t>For example, a single text/plain object (Content-Format 0) of value
"Hello World" (11 characters) would be serialized as follows:</t>
<artwork><![CDATA[0x82 0x00 0x4b H e l l o 0x20 W o r l d]]>
</artwork>
<texttable title="Serialization of content-format" anchor="tbl-integer"> <t>In effect, the serialization for a single object is done by prefixing
<ttcol align='left'>Serialization</ttcol> the object with information that there is one object (here: 0x82),
<ttcol align='left'>Value</ttcol> information about its Content-Format (here: 0x00), and information
<c>0x00..0x17</c> regarding its length (here: 0x4b).</t>
<c>0..23</c>
<c>0x18 0xnn</c>
<c>24..255</c>
<c>0x19 0xnn 0xnn</c>
<c>256..65535</c>
</texttable>
<texttable title="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 0xnn 0xnn</c>
<c>256..65535</c>
<c>0x5a 0xnn 0xnn 0xnn 0xnn</c>
<c>65536..4294967295</c>
<c>0x5b 0xnn .. 0xnn (8 bytes)</c>
<c>4294967296..</c>
</texttable>
<t>For example, a single text/plain object (content-format 0) of value
“Hello World” (11 characters) would be serialized as</t>
<t><list style='empty'>
<t>0x82 0x00 0x4b H e l l o 0x20 W o r l d</t>
</list></t>
<t>In effect, the serialization for a single object is done by prefixing
the object with information that there is one object (here: 0x82),
about its content-format (here: 0x00) and 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, …) and
the sequences of content-format and embedded representations follow.</t>
<t>For instance, the example from <xref target="encoding"/> would be serialized
as:</t>
<t><list style='empty'>
<t>0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x3031323334</t>
</list></t>
<t>where (*) marks the start of the information about the first
representation (content-format 42, byte string length 8) and, (+), of
the second representation (content-format 0, byte string length 5).</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="registration-of-media-type-applicationmultipart-core" title="Re <t>For more than one representation included in an
gistration of media type application/multipart-core"> 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 and embedded representations follow.</t>
<t>For instance, the example from <xref target="encoding"
format="default"/> would be serialized as follows:</t>
<artwork><![CDATA[0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x303132
3334]]>
</artwork>
<t>IANA is requested to register the following media type <xref target="RFC6838" <t>where (*) marks the start of the information about the first
/>:</t> representation (Content-Format 42, byte string length 8), and (+) marks
the start of the second representation (Content-Format 0, byte string
length 5).</t>
</section>
<t><list style="hanging"> <section anchor="IANA" numbered="true" toc="default">
<t hangText='Type name:'> <name>IANA Considerations</name>
application</t> <section anchor="registration-of-media-type-applicationmultipart-core" num
<t hangText='Subtype name:'> bered="true" toc="default">
multipart-core</t> <name>Registration of Media Type application/multipart-core</name>
<t hangText='Required parameters:'> <t>IANA has registered the following media type <xref target="RFC6838" f
N/A</t> ormat="default"/>:</t>
<t hangText='Optional parameters:'> <dl newline="false" spacing="normal">
N/A</t> <dt>Type name:</dt>
<t hangText='Encoding considerations:'> <dd>
binary</t> application</dd>
<t hangText='Security considerations:'> <dt>Subtype name:</dt>
See the Security Considerations Section of RFCthis</t> <dd>
<t hangText='Interoperability considerations:'> multipart-core</dd>
N/A</t> <dt>Required parameters:</dt>
<t hangText='Published specification:'> <dd>
RFCthis</t> N/A</dd>
<t hangText='Applications that use this media type:'> <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 of 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:</dt>
<dd>
Applications that need to combine representations of zero or more different Applications that need to combine representations of zero or more different
media types into one, e.g., EST-CoAP <xref target="I-D.ietf-ace-coap-est"/></t> media types into one, e.g., EST over secure CoAP (EST-CoAP) <xref target="I-D.ie
<t hangText='Fragment identifier considerations:'> tf-ace-coap-est" format="default"/></dd>
<dt>Fragment identifier considerations:</dt>
<dd>
The syntax and semantics of fragment identifiers specified for The syntax and semantics of fragment identifiers specified for
“application/multipart-core” is as specified for “application/cbor”. application/multipart-core are as specified for application/cbor. (At
(At publication of this document, there is no fragment publication of this document, there is no fragment identification syntax
identification syntax defined for “application/cbor”.)</t> defined for application/cbor.)</dd>
<t hangText='Additional information:'> <dt>Additional information:</dt>
<list style="hanging"> <dd>
<t hangText='Deprecated alias names for this type:'> <ul>
N/A</t> <li>Deprecated alias names for this type: N/A</li>
<t hangText='Magic number(s):'> <li>Magic number(s): N/A</li>
N/A</t> <li>File extension(s): N/A</li>
<t hangText='File extension(s):'> <li>Macintosh file type code(s):N/A</li>
N/A</t> </ul>
<t hangText='Macintosh file type code(s):'> </dd>
N/A</t> <dt>Person &amp; email address to contact for further information:</dt
</list> >
</t> <dd>
<t hangText='Person &amp; email address to contact for further information:'> iesg@ietf.org</dd>
iesg&amp;ietf.org</t> <dt>Intended usage:</dt>
<t hangText='Intended usage:'> <dd>
COMMON</t> COMMON</dd>
<t hangText='Restrictions on usage:'> <dt>Restrictions on usage:</dt>
N/A</t> <dd>
<t hangText='Author:'> N/A</dd>
CoRE WG</t> <dt>Author:</dt>
<t hangText='Change controller:'> <dd>
IESG</t> CoRE WG</dd>
<t hangText='Provisional registration? (standards tree only):'> <dt>Change controller:</dt>
no</t> <dd>
</list></t> IESG</dd>
<dt>Provisional registration? (standards tree only):</dt>
</section> <dd>
<section anchor="registration-of-a-content-format-identifier-for-applicationmult no</dd>
ipart-core" title="Registration of a Content-Format identifier for application/m </dl>
ultipart-core"> </section>
<section anchor="registration-of-a-content-format-identifier-for-applicati
<t>IANA is requested to register the following Content-Format to the onmultipart-core" numbered="true" toc="default">
“CoAP Content-Formats” subregistry, within the “Constrained RESTful <name>Registration of a Content-Format Identifier for application/multip
Environments (CoRE) Parameters” registry, from the Expert Review space art-core</name>
(0..255):</t> <t>IANA has registered the following Content-Format in the "CoAP
Content-Formats" subregistry within the "Constrained RESTful
<texttable> Environments (CoRE) Parameters" registry:</t>
<ttcol align='left'>Media Type</ttcol> <table align="center">
<ttcol align='left'>Encoding</ttcol> <name>Addition to "CoAP Content-Formats" Registry</name>
<ttcol align='left'>ID</ttcol> <thead>
<ttcol align='left'>Reference</ttcol> <tr>
<c>application/multipart-core</c> <th align="left">Media Type</th>
<c>—</c> <th align="left">Encoding</th>
<c>TBD1</c> <th align="left">ID</th>
<c>RFCthis</c> <th align="left">Reference</th>
</texttable> </tr>
</thead>
</section> <tbody>
</section> <tr>
<section anchor="Security" title="Security Considerations"> <td align="left">application/multipart-core</td>
<td align="left">-</td>
<t>The security considerations of <xref target="RFC7049"/> apply. In particular <td align="left">62</td>
, <td align="left">RFC 8710</td>
resource exhaustion attacks may employ large values for the byte string </tr>
size fields, or deeply nested structures of recursively embedded </tbody>
application/multipart-core representations.</t> </table>
</section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations of <xref target="RFC7049" format="default"/>
apply. In particular, resource exhaustion attacks may employ large values for
the byte string size fields or employ deeply nested structures of recursively
embedded application/multipart-core representations.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.ietf-ace-coap-est" to="EST-COAPS"/>
<references>
<reference anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'> <name>References</name>
<front> <references>
<title>Concise Binary Object Representation (CBOR)</title> <name>Normative References</name>
<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 wh
ose design goals include the possibility of extremely small code size, fairly sm
all message size, and extensibility without the need for version negotiation. T
hese design goals make it different from earlier binary serializations such as A
SN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>
<reference anchor="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 /></au
thor>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></au
thor>
<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 tr
ansfer protocol for use with constrained nodes and constrained (e.g., low-power,
lossy) networks. The nodes often have 8-bit microcontrollers with small amount
s of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireles
s Personal Area Networks (6LoWPANs) often have high packet error rates and a typ
ical throughput of 10s of kbit/s. The protocol is designed for machine- to-mach
ine (M2M) applications such as smart energy and building automation.</t><t>CoAP
provides a request/response interaction model between application endpoints, sup
ports 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 inte
rface with HTTP for integration with the Web while meeting specialized requireme
nts 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 Comm
unity, 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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 /></auth
or>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'><organizatio
n /></author>
<date year='1996' month='November' />
<abstract><t>This second document defines the general structure of the MIME medi
a 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 /></au
thor>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful applicatio
n protocol for constrained nodes and networks. The state of a resource on a CoA
P server can change over time. This document specifies a simple protocol extens
ion for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., t
o retrieve a representation of a resource and keep this representation updated b
y the server over a period of time. The protocol follows a best-effort approach
for sending new representations to clients and provides eventual consistency be
tween the state observed by each client and the actual resource state at the ser
ver.</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 pro
visioning protocol over HTTPS. Low-resource devices often use the lightweight C
onstrained Application Protocol (CoAP) for message exchanges. This document def
ines how to transport EST payloads over secure CoAP (EST-coaps), which allows co
nstrained devices to use existing EST functionality for provisioning certificate
s.</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.t
xt' />
</reference>
<reference anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'>
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Expre
ss Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization />
</author>
<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></au
thor>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<date year='2019' month='June' />
<abstract><t>This document proposes a notational convention to express Concise B
inary Object Representation (CBOR) data structures (RFC 7049). Its main goal is
to provide an easy and unambiguous way to express structures for protocol messa
ges and data formats that use CBOR or JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8610'/>
<seriesInfo name='DOI' value='10.17487/RFC8610'/>
</reference>
<reference anchor="RFC6838" target='https://www.rfc-editor.org/info/rfc6838'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7049.
<front> xml"/>
<title>Media Type Specifications and Registration Procedures</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></auth xml"/>
or> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></ xml"/>
author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></au xml"/>
thor> </references>
<date year='2013' month='January' /> <references>
<abstract><t>This document defines procedures for the specification and registra <name>Informative References</name>
tion of media types for use in HTTP, MIME, and other Internet protocols. This m <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.
emo documents an Internet Best Current Practice.</t></abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.
<seriesInfo name='BCP' value='13'/> xml"/>
<seriesInfo name='RFC' value='6838'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
<seriesInfo name='DOI' value='10.17487/RFC6838'/> xml"/>
</reference> <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> </references>
<section numbered="false" anchor="acknowledgements" toc="default">
<section numbered="no" anchor="acknowledgements" title="Acknowledgements"> <name>Acknowledgements</name>
<t>Most of the text in this document is from earlier contributions by
<t>Most of the text in this draft is from earlier contributions by two of two of the authors, <contact fullname="Thomas Fossati"/> and <contact
the authors, Thomas Fossati and Klaus Hartke. The re-mix in this fullname="Klaus Hartke"/>. This earlier work was reorganized in this docu
document is based on the requirements in <xref target="I-D.ietf-ace-coap-est"/>, ment based on the
based on requirements in <xref target="I-D.ietf-ace-coap-est" format="default"/>
discussions with Michael Richardson, Panos Kampanis and Peter van der and discussions with <contact fullname="Michael Richardson"/>,
Stok.</t> <contact fullname="Panos Kampanis"/>, and <contact fullname="Peter van
der Stok"/>.</t>
<!-- LocalWords: multipart
-->
</section>
</section>
</back> </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> </rfc>
 End of changes. 49 change blocks. 
634 lines changed or deleted 387 lines changed or added

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