One document matched: draft-fossati-core-multipart-ct-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- vim: set ts=2 expandtab: -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-12.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?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" ?>
<rfc category="std" docName="draft-fossati-core-multipart-ct-01" ipr="trust200902">
  <front>
    <title abbrev="Multipart Content Format for CoAP">
      Multipart Content Format Encoding for CoAP
    </title>
    <author
      fullname="Thomas Fossati"
      initials="T.F."
      surname="Fossati"
    >
      <organization>KoanLogic</organization>
        <address>
          <postal>
            <street>Via di Sabbiuno, 11/5</street>
            <city>Bologna</city>
            <code>40100</code>
            <country>Italy</country>
        </postal>
        <email>tho@koanlogic.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>CoAP, Multipart Content Format</keyword>

    <abstract>
      <t>This memo defines a new content format encoding that can be used to combine several different media types into a single CoAP message-body.  The proposed encoding provides a cheap framing facility aimed at minimizing the overhead bits as much as possible.</t>
      <t>Its main use case is for applications whose purpose is as simple as just pulling together a number of known content formats, with the caveat that their juxtaposition must not raise any semantic ambiguity on the receiving side (i.e. strictly ordered, with no optional parts).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This memo defines a new media type encoding that can be used to combine several different media types into a single CoAP message-body.</t>
      
      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />.</t>
      </section>
    </section>

    <section title="Multipart Content-Format Encoding">
      <t>Multipart encoding uses multiple adjacent frames each of which represents a single media.  Every frame can further be broken in three logical pieces: the type of the framed media (T), its length in bytes (L), and the media payload itself (V) as depicted in the following figure.</t>

      <figure>
        <artwork align="center"><![CDATA[
,------------------ multi part -----------------.
+------+------+------+     +------+------+------+
| T[0] | L[0] | V[0] | ... | T[n] | L[n] | V[n] |
+------+------+------+     +------+------+------+
`------ part 0 ------'     `------ part n ------'
        ]]></artwork>
      </figure>
    
      <t>
        The semantics associated to the TLV atoms is as follows:
        <list style="hanging">
          <t hangText="T:"> is one of the numeric content format identifiers defined in the CoAP Content-Format Registry (Section 12.3 of <xref target="I-D.ietf-core-coap" />), and is encoded as a 16-bit uint (Section 3.4.1. of <xref target="I-D.ietf-core-coap" />).</t>
          <t hangText="L:"> is the lentgh in bytes of the following V frame, and has two possible encodings: short or extended (see <xref target="length-encoding" />).  It determines the offset of the next part, or the end of the multipart representation when applied to the last frame.</t>
          <t hangText="V:"> is the media, encoded as implied by the preceding T field.</t>
        </list>
      </t>
    </section>

    <section title="Length Encoding" anchor="length-encoding" >
      <t>Two different encodings are defined for the L value: short for parts where length(V) measured in bytes is in range [0, 32767]; extended for parts with length(V) in range (32767, 2^127-1].</t>

      <section title="Short">
        <t>The short format uses a fixed 16-bit uint with the most significant bit set to '0'. The remaining 15 bits encode a length(V) value up to 32767 bytes.</t>
        <figure>
          <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|          0-32767            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
        </figure>
      </section>

      <section title="Extended">
        <t>The extended format uses a fixed 8-bit uint with the most significant bit set to '1'. The remaining 7 bits encode the number of bytes needed to uint-encode the length(V) bytes.</t>
        <figure>
          <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+------/   /------+
|1|    0-127    |   0-(2^127-1)   |
+-+-+-+-+-+-+-+-+------/   /------+
      ]]></artwork>
        </figure>
      </section>

      <section title="Constraints">
        <t>The most compact encoding MUST be used, i.e.:
          <list style="numbers">
            <t>always use the short encoding when length(V) < 32768; </t>
            <t>never zero-pad the most significant byte when using the extended encoding.</t>
          </list>
        </t>
        <t>The former implies that 0x81 would be an invalid value for the first octet, and that in case the first octet is 0x82 the length(V) value MUST be > 0x7FFF.</t>
      </section>

      <section title="Examples">
      <t>
        A length of 32767 bytes would use short encoding:
        <figure>
          <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S          len=32767
      ]]></artwork>
        </figure>
      </t>

      <t>
        A length of 32768 bytes would use extended encoding with length of length 2:
        <figure>
          <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0 0 0 1 0|1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 E   lenlen=2            len=32768
      ]]></artwork>
        </figure>
      </t>

      </section>
    </section>

<!--
    <section title="Interaction with Block Transfer">
      <t>any?</t>
    </section>
-->

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
    <?rfc needLines="8" ?>

    <section anchor="IANA" title="IANA Considerations">
      <t>The following entry is added to the CoAP Content Format registry:</t>
      <figure align="center">
        <artwork><![CDATA[
.--------------------------------.
| Number | Name      | Reference |
:--------:-----------:-----------:
|  n     | Multipart | RFC XXXX  |
`--------------------------------'
        ]]></artwork>
      </figure>
      <t>When used as the payload in a CoAP message, one Content-Format option MUST be present and set to n.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The extended encoding may trigger insanely huge buffer allocations on the receiving party.  Receivers of multipart media SHOULD put a cap on the maximum allowed size of the whole Multipart.  A CoAP server MAY respond with a 4.13 (Request Entity Too Large) status code to such requests, and refuse to proceed further (e.g. processing more blocks).</t>
      <t>A CoAP client can't tell if a 4.15 status code applies to the whole Multipart or just to one of its parts.  An attacker may leverage on this ambiguity to craft application specific attacks (e.g. cause downgraded behavior).  Applications built on top of Multipart need to handle such eventuality in a safe way.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &I-D.ietf-core-coap;
    </references>
  </back>
</rfc>