<?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.5 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-roll-ccast-01" category="std">

  <front>
    <title abbrev="Constrained-Cast">Constrained-Cast: Source-Routed Multicast for RPL</title>

    <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
      <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-63904</phone>
        <email>bergmann@tzi.org</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>
    <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
      <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-63906</phone>
        <email>gerdes@tzi.org</email>
      </address>
    </author>
    <author initials="H." surname="Chen" fullname="Hao Chen">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>12, E. Mozhou Rd</street>
          <city>Nanjing</city>
          <code>211111</code>
          <country>China</country>
        </postal>
        <phone>+86-25-5662-7052</phone>
        <email>philips.chenhao@huawei.com</email>
      </address>
    </author>

    <date year="2017" month="October" day="30"/>

    <area>Routing</area>
    <workgroup>Roll Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This specification defines a protocol for forwarding multicast traffic
in a constrained node network employing the RPL routing protocol in
non-storing mode.</t>



    </abstract>


  </front>

  <middle>


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

<t>As defined in <xref target="RFC6550"/>, RPL Multicast assumes that the RPL network
operates in Storing Mode.  Multicast DAOs are used to indicate
subscription to multicast address to a parent; these DAOs percolate up and create bread-crumbs.
This specification, although part of RFC 6550, appears to be
incomplete and untested.
More importantly, Storing Mode is not in use in constrained node
networks outside research operating environments.</t>

<t>The present specification addresses multicast forwarding for RPL
networks in the much more common Non-Storing Mode.  Non-Storing is
based on the root node adding source-routing information to downward
packets.  Evidently, to make this work, RPL multicast needs to
source-route multicast packets.  A source route here is a list of
identifiers to instruct forwarders to relay the respective IP
datagram.</t>

<t>As every forwarder in an IP-based constrained node network has at
least one network interface, it is straight-forward to use the address
of an outgoing interface as identifiers in this
source-route. (Typically, this is a globally unique public address of
the node’s only network adapter.)</t>

<t>The source-route subsets the whole set of potential forwarders
available in the RPL DODAG to those that need to forward in order to
reach known multicast listeners.</t>

<t>Including an actual list of outgoing interfaces is rarely applicable,
as this is likely to be a large list of 16-byte IPv6 addresses.
Even with <xref target="RFC6554"/> style compression, the size of the list becomes
prohibitively quickly.</t>

<section anchor="terminology" title="Terminology">

<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>

<t>In this specification, the term “byte” is used in its now customary
sense as a synonym for “octet”.</t>

<t>All multi-byte integers in this protocol are interpreted in network
byte order.</t>

</section>
</section>
<section anchor="the-bier-approach" title="The BIER Approach">

<t>Bit-Indexed Explicit Replication <xref target="I-D.ietf-bier-architecture"/>
lists all egress routers in a bitmap included in each multicast
packet.  This requires creating a mostly contiguous numbering of all
egress routers; more importantly, BIER requires the presence of a
network map in each forwarders to be able to interpret the bitmap and
map it to a set of local outgoing interfaces.</t>

</section>
<section anchor="the-constrained-cast-approach" title="The Constrained-Cast Approach">

<t>Constrained-Cast employs Bloom Filters <xref target="BLOOM"></xref> as a compact representation of
a match or non-match for elements in a large set:
Each element to be included is hashed with multiple hash functions;
the result is used to index a bitmap and set the corresponding bit.
To check for the presence of an element, the same hash functions are
applied to obtain bit positions; if all corresponding bits are set,
this is used to indicate a match.
(Multiple hash functions are most easily obtained by adding a varying
seed value to a single hash algorithm.)</t>

<t>By including a bloom filter in each packet that matches all outgoing
interfaces that need to forward the packet, each forwarder can
efficiently decide whether (and on which interfaces) to forward the packet.</t>

</section>
<section anchor="false-positives" title="False Positives">

<t>Bloom filters are probabilistic.  A false positive might be
indicating a match where the bits are set by aliasing of the hash
values.
In case of Constrained-Cast, this causes spurious transmission and
wastes some energy and radio bandwidth.
However, there is no semantic damage (hosts still filter out unneeded multicasts).
The total waste in energy and spectrum can be visualized as the
false-positive-rate multiplied by the density of the RPL network.
A network can easily live with a significant percentage of false positives.
By changing the set of hash functions (i.e., seed) over time, the
root can avoid a single node with a false positive to become an
unnecessary hotspot for that multicast group.</t>

</section>
<section anchor="protocol" title="Protocol">

<t>The protocol uses DAO-like “MLAO” messages to announce membership to
the root as specified in <xref target="mlao"/>.</t>

<t>For downward messages, the root adds a new routing header that
includes a hash function identifier and a seed value; another one of
its fields gives the number of hash functions (k) to ask for k
instances of application of the hash function, with increasing seed.
The format of the new routing header is specified in <xref target="rh"/>.</t>

<t>Typical sizes of the bloom filter bitmap that the root inserts into
the packet can be 64, 128, or 256 bit, which may lead to acceptable
false positive rates if the total number of forwarders in the 10s and
100s.  (To do: write more about the math here.  Note that this number
tallies forwarding routers, not end hosts.)</t>

<t>A potential forwarder that receives a multicast packet adorned with a
constrained-cast routing header first checks that the packet is marked
with a RPL rank smaller than its own (loop prevention).  If yes, it
then forwards the packet to all outgoing interfaces that match the
bloom filter in the packet.</t>

<section anchor="mlao" title="Multicast Listener Advertisement Object (MLAO)">

<t>The header format of the MLAO is depicted in
<xref target="target-option"/>.  The basic structure of the MLAO message is similar
to the RPL Destination Advertisement Object (DAO). In particular, it
starts with RPL ICMP base header with a type value of 155 and the code
{IANA TBD1} (MLAO), followed by the Checksum, RPLInstanceID, parameters and
flags as in a DAO. <!-- WHAT? -->
<!-- A sequence number allows ordering of MLAOs -->
<!-- generated by a sender. --></t>

<figure title="RPL Target Option for MLAO" anchor="target-option"><artwork><![CDATA[
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x05 | Option Length |   Reserved    | Prefix Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +                                                               +
       |                     Group Address                             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The group address field indicates the group that the sender of the MLAO is
interested in. This field usually contains a 128 bit IPv6 multicast
group address. Shorter group identifiers could be used together with a
protocol for explicit creation of groups.  The MLAO message must have
at least one RPL target option to specify the address of the listener
that has generated the MLAO. The message is directed to the global
unicast address of the DODAG root and travels upwards the routing tree.</t>

<t><list style="hanging">
  <t hangText='Note:'>
  It has been suggested to use the RPL Transit Option (Type 0x06)
instead as it is used in Non-Storing mode to inform the DODAG root
of path attributes.  Specifically, this option can be used to limit
the subscription by providing a proper Path Lifetime.</t>
</list></t>

</section>
<section anchor="rh" title="Routing Header">

<t>This specification uses a new Soure Routing 6LowPAN Routing Header
(SRH-6LoRH) type <xref target="RFC8138"/> to convey the Bloom filter that describes
the source route for the IPv6 multicast packet to take within the RPL
routing tree. The 6LoRH Type for this Constrained Cast Routing Header
(CCRH) is set to TBD7. <xref target="rh-format"/> depicts the format of this new
routing header.</t>

<figure title="Routing header" anchor="rh-format"><artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|rsv|BSize| 6LoRH Type 7  | Func set      |    Modulus    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sequence Number                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                       Filter data                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t><list style="hanging">
  <t hangText='rsv: This field is reserved for future use an MUST be set to 0 when'>
  sending a packet containing a CCRH. A receiver MUST ignore the value
of the rsv field.</t>
  <t hangText='BSize:'>
  Specifies the size of the included Bloom filter. Currently, only 
64 bits, 128 bits, or 256 bits are supported. The BSize field is
encoded as specified in <xref target="rh-bsize"/>.</t>
</list></t>

<texttable title="Possible Bloom Filter Lengths" anchor="rh-bsize">
      <ttcol align='left'>BSize value</ttcol>
      <ttcol align='left'>Filter Size (Bits)</ttcol>
      <c>0</c>
      <c>64</c>
      <c>1</c>
      <c>128</c>
      <c>2</c>
      <c>256</c>
</texttable>

<t><list style="hanging">
  <t hangText='Func set:'>
  The set of hash functions used to generate the Filter data value.</t>
</list></t>

<t>Note: As the function set contains a combination of several distinct
hash functions, it is currently unclear if 8 bits number space is
large enough.</t>

<t><list style="hanging">
  <t hangText='Modulus:'>
  The modulus that is used by the hash functions, minus 64 (the
minimum filter data size that can be used).  The DAG root chooses the
modulus (and thus the filter data size) to achieve its objectives
for false positive rates (<xref target="false-positives"/>).</t>
  <t hangText='Sequence Number:'>
  32 bits sequence number. The number space is unique for a sequence
of multicast datagrams for a specific group that arrive at the DAG
root on their way up.  The DAG root increments the number for each
datagram it sends down the respective DODAG.</t>
  <t hangText='Filter data:'>
  A bit field that indicates which nodes should relay this multicast
datagram. The length of this field is a multiple of 8 bytes
(2^(BSize + 3) bytes). The actual length is derived from the
contents of the field BSize.</t>
</list></t>

</section>
</section>
<section anchor="implementation" title="Implementation">

<t>In 2013, Constrained-Cast was implemented in Contiki.  It turns out
that forwarders can compute the hash functions once for their outgoing
interfaces and then cache them, simply bit-matching their outgoing
interface hash bits against the bloom filter in the packet (a match is
indicated when all bits in the outgoing interface hash are set in the
bloom filter).</t>

<t>The Root computes the tree for each multicast group, computes the
bloom filter for it, caches these values, and then simply adds the
bloom filter routing header to each downward packet.  For adding a new
member, the relevant outgoing interfaces are simply added to the bloom
filter.  For removing a leaving member, however, the bloom filter
needs to be recomputed (which can be sped up logarithmically if
desired).</t>

</section>
<section anchor="benefits" title="Benefits">

<t>Constrained-Cast:</t>

<t><list style="symbols">
  <t>operates in Non-Storing Mode, with the simple addition of a
membership information service;</t>
  <t>performs all routing decisions at the root.</t>
</list></t>

<t>Further optimizations might include using a similar kind of bloom
filter routing header for unicast forwarding as well (representing,
instead of the outgoing interface list, a list of children that
forwarding parents need to forward to).</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>TODO</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The following registrations are done following the procedure specified
in <xref target="RFC6838"/>.</t>

<t>Note to RFC Editor: Please replace all occurrences of “&SELF;” with
the RFC number of this specification and “TBD1” with the code
selected for TBD1 below and “TBD7” with the code selected for TBD7.</t>

<section anchor="icmpv6-parameter-registration" title="ICMPv6 Parameter Registration">

<t>IANA is requested to add the following entry to the Code fields of the
RPL Control Codes registry:</t>

<texttable>
      <ttcol align='center'>Code</ttcol>
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>TBD1</c>
      <c>MLAO</c>
      <c>&SELF;</c>
</texttable>

</section>
<section anchor="critical-6lowpan-routing-header-type-registration" title="Critical 6LowPAN Routing Header Type Registration">

<t>IANA is requested to add the following entries to the Critical 6LowPAN
Routing Header Type Registration registry:</t>

<texttable>
      <ttcol align='center'>Value</ttcol>
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>TBD7</c>
      <c>CCast Routing Header</c>
      <c>&SELF;</c>
</texttable>

</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>Thanks to Yasuyuki Tanaka for valuable comments.</t>

<t>This work has been supported by Siemens Corporate Technology.</t>

<!--  LocalWords:  Datagram CoAP CoRE DTLS DCAF DCAF's introducer URI
 -->
<!--  LocalWords:  namespace Verifier JSON timestamp timestamps PSK
 -->
<!--  LocalWords:  decrypt UTC decrypted whitespace preshared HMAC
 -->
<!--  LocalWords:  multicast RPL DAOs DODAG IPv multicasts DAO MLAO
 -->
<!--  LocalWords:  datagrams datagram Contiki logarithmically unicast
 -->

</section>


  </middle>

  <back>

    <references title='Normative References'>





<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>



<reference  anchor="RFC8138" target='https://www.rfc-editor.org/info/rfc8138'>
<front>
<title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header</title>
<author initials='P.' surname='Thubert' fullname='P. Thubert' role='editor'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='L.' surname='Toutain' fullname='L. Toutain'><organization /></author>
<author initials='R.' surname='Cragie' fullname='R. Cragie'><organization /></author>
<date year='2017' month='April' />
<abstract><t>This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550).  Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.</t></abstract>
</front>
<seriesInfo name='RFC' value='8138'/>
<seriesInfo name='DOI' value='10.17487/RFC8138'/>
</reference>



<reference  anchor="RFC6550" target='https://www.rfc-editor.org/info/rfc6550'>
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author initials='T.' surname='Winter' fullname='T. Winter' role='editor'><organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert' role='editor'><organization /></author>
<author initials='A.' surname='Brandt' fullname='A. Brandt'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='R.' surname='Kelsey' fullname='R. Kelsey'><organization /></author>
<author initials='P.' surname='Levis' fullname='P. Levis'><organization /></author>
<author initials='K.' surname='Pister' fullname='K. Pister'><organization /></author>
<author initials='R.' surname='Struik' fullname='R. Struik'><organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
<author initials='R.' surname='Alexander' fullname='R. Alexander'><organization /></author>
<date year='2012' month='March' />
<abstract><t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6550'/>
<seriesInfo name='DOI' value='10.17487/RFC6550'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.ietf-bier-architecture">
<front>
<title>Multicast using Bit Index Explicit Replication</title>

<author initials='I' surname='Wijnands' fullname='IJsbrand Wijnands'>
    <organization />
</author>

<author initials='E' surname='Rosen' fullname='Eric Rosen'>
    <organization />
</author>

<author initials='A' surname='Dolganow' fullname='Andrew Dolganow'>
    <organization />
</author>

<author initials='T' surname='Przygienda' fullname='Tony Przygienda'>
    <organization />
</author>

<author initials='S' surname='Aldrin' fullname='Sam Aldrin'>
    <organization />
</author>

<date month='September' day='13' year='2017' />

<abstract><t>This document specifies a new architecture for the forwarding of multicast data packets.  It provides optimal forwarding of multicast packets through a "multicast domain".  However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER).  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The procedures for forwarding a packet based on its BIER header are specified in this document.  Elimination of the per-flow state and the explicit tree- building protocols results in a considerable simplification.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-bier-architecture-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-bier-architecture-08.txt' />
</reference>


<reference anchor="BLOOM" target="http://doi.acm.org/10.1145/362686.362692">
  <front>
    <title>Space/time trade-offs in hash coding with allowable errors</title>
    <author initials="B.H." surname="Bloom" fullname="Burton H. Bloom">
      <organization></organization>
    </author>
    <date year="1970"/>
  </front>
  <seriesInfo name="ISSN" value="0001-0782"/>
  <seriesInfo name="ACM Press" value="Communications of the ACM vol 13 no 7 pp 422-426"/>
</reference>




<reference  anchor="RFC6554" target='https://www.rfc-editor.org/info/rfc6554'>
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></author>
<date year='2012' month='March' />
<abstract><t>In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes.  In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN.  The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers.  This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6554'/>
<seriesInfo name='DOI' value='10.17487/RFC6554'/>
</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>



  </back>

<!-- ##markdown-source:
H4sIAPOm91kAA81b63YbR3L+P0/RS52TJWMMDIAXUXC8uyBIWdyQIkNS62x8
nJzGTAPo5cw0PBfSMMU8Td4kL5avqnoGAxDKHlv6sfCxBMz0pbquX1W1wjAM
IhfbbDZUVTkNj4OgtGVihuoPgVJjlxVlrm1m4nCsi3Kobl2VRya8cVVpYnVZ
JaWN8EJNXa5uri8CPZnk5mH4YmYQuyjTKdaNcz0tQ2uwWe6SJIxofpjo0tAo
/DVUg17/ddjvhfu9IMKDmcuXQ1WUcRDYRT5UZV4V5aDXe9MbBDo3eqiIHBwh
eHT5/Sx31YIeJYn6Hr/xXH1Hz4J7s8SAeKjOs9LkmSnDU6IlCIpSZ/F/6cRl
2HxpimBhh+qH0kUdVbi8zM20wLdlKl8ily50VP4YBLoq5y4fBioEr5SyWTFU
V111YvJZqrOMH8qhrxI9XX/u8pnO7C+6tC4bqg+ZfTB5Ycv//Z9SneQmNZm6
+49zHgk+GgPWX7uinOporvb3ewcHPX4X2RKskQnywMXY7jQcHO8fvvFPqqwk
Bn5ncuy+5IeLOZ/1q4M34cGgHw76x+HR/pveAb80qbbJUE08uX8qf7FdkLt2
zDGO6fKNU451XpSgvP0GE/9Rjjfot48X6YnberTbLq0VQw1WJ7stzRTiMu03
/0An6x21TzZjGree7V1XjeemLbN32q0e8ZHeVfrRWHVnonnmEjez/rz1cfqD
jjrrqkv3y9xV6iZunee9zv5Gdrg60KBPn/XzjOc202unOT4KB4fh4dHRIHzd
Oxy0D7OY28Quim4EGufa/WnO1HVhhAE+GWlaCRHACNXN2zG2e+O/HvdfHzRf
94+HcB7ZtD38PDztshuaWJOHOo/mtjRRWeWgiB5hyMnF1dXlkMlpbB2fUJi5
c9Ilhp4kzqU7/KJm6s5JlZcu23hbmBy8JCqGfvT57e17jO71ev2w9/p4UK+y
MxpfquvcFMUOXo9dmlYZ/Cz5ikK5qSrnRtGQB5eo/r7KnHqtFgt1MBhAK45k
Fe/Gd27hrMzXpU0NHKeOTeim0wIHUHNdzJX4fvVoy7nSSeIe9SQxyuS5ywu/
js5nJPadeVkuhl9/HTvb1VFKqvV1v9ft9w8Ov94/GhwdH3Xprzf+EOLJ+29e
94LAZCWphz+cUrdnF2+x4A8QTfjv+Py4EwRhGCo9oZgRwSPfzW2hioWJ7NSf
W8VmimhSKK0WuYNvxtEp6OD/R53zIdImGmGVKSZC4hgerUIROBUbBc9PgQIa
tkjckmYSPxG9VC5xZLWDzaBiWViULucdML0rtKY2jhMDFXxF4SR3cRURmUEw
KjypMTH56el3OOXR4WHv+bnDe6xipi6KKsWJyrkuGxI8cYFbmJxiIi1y67e/
pO1Va4XT0RUYkhtVFdiudBgcE79MUFSTIsrtglmHFyve6DgmxaKHYCUmZ+U3
tHthZDnsi5NjDVUtFOKiihBi8QtxXcdhlFfppOhuEVAH+gMTqWZzWrUkNcXJ
FR0drxYLg+BAm04MxEIxNDFYlTaAW0DsN3E3uHQ4i00XCLo6K5NlZ+3oCltm
riSO4Lz016ZoA889GElVFhZTcFRDpq2En7SUyR5s7jI43hIHwUkM5I1hWbmh
cZ5TkEHaxjm1utWQp9kTBJEU0wrbpXQSnDLFOu+hQRsibD+yRTDRJD8n83OH
M7KiggAaUAjmqpWzcWMi2dg9ZkRSADu/NziSUmcPOLrwj0Sv72H6JC8iU5Rw
daDMmJjkErR2Ma33q1VHnhAlQ+YmZ4loldiCxB3wpmCfEUFbkg2souaZf5yb
RC/loIb4Te5YnV8T9NOzXKddNiGDqLpczSTe6gzDQmHVJ20aTk3pMkgM0Y7g
0rywhPkQhU1H2ZLo5vmzeRn6TYg2UiuizEs+gA5jVxx35oTzfg2YrmqfliUP
ObZ52FW7d8sFmJiwHIj/zK1Z4ib0DGpvf6qge9UksVFjluAjUUCH+j1+ZRhY
H0HHegECunuitGsCI3uHmJj6x7mDD8dPssGFK4lOnbTEEOgHxFb29F5nSSdO
r05H3xEXYMXMBy3aQY9qHmG4Y3lAYeAPoOj3GfSvpS+kDCbDJpDjeRYlFasw
uAi/XoEKryxbmMr8yeGQcGT4CzCFKOwEumi4l9h7estehBSPQlOzYv8onCxL
0qWHo5XtdoOzB2AyDnBPT38UZ3zw/Az5LxM2UTL+gh0YcaKwv5g6xPLKE4Mx
lBPkbm4nltQVJPxU2eg+WeKQr14BKuWpZay0FNEg0yBjg2HtXH64vdvpyN/q
/RV/vzn7tw/nN2en9P323ejiovkiIwL8uPpw4d/Tt9XM8dXl5dn7U5mMp2rj
0eXor/gLbjXYubq+O796P7rYqfUTviKqyO9xzBAuMvvBAkrnNIUuChsTCV4n
4+ugfwC2eWQFrvF3glb4/ghIxluJmspP8G3p3T0bbZIgh1vYUidInbBBMSd9
IefBCiJ0bQQS4j2oStUOCXSHJM8BDuvZkmLAo4qQArpU58sAjrtgg9RI0RCs
lyl75h0XlabcIW+CRJD1U9SDDjxrGe0q2BNT2uzAgDoa80zWfJK4IhmfnJ/d
qNECs2EGQXBiy/A8i83PmHj2M2kv3MyNYTVmV/30xEDz+TkgtSqIM8rM2ObZ
hIUiDehZpnqB72Q7QgUbWmNi3tHDI3MQzg10EctInGZjQ/Qp4P3JS5Z2VrkK
PEPYNhxuyKdBKOtbfyMBay308gGb1csmTEZsH7qOe0qoFSLXXT0ZKTkZDgae
r7yQPyNpKc8uBY14l5U4OM1tDqLh/WZ1oSWHF68E5RUCxNVbmzCrf2Bo/6Po
jc/ocVgPBERicMVgpS4JPeSKcKD8IPUyiWEAITITRwTyh8EZscG/bUysFmXB
oBvf2B2xRAGDBIlPq4wRZPFN4IMjXjeqL9jO/LxSELK7wvMzcjkFU5exs8UA
ADSnkDJF90ztC+FlNYne6SFr2aCCrCFgNyy7u0kJptLaCCnId5lSZVmZXu4v
qBTkdYLad29CVOV52w12L7czgtcgVYZuFRb6LDRgmcmyxkZaPcAJUM5ZUKh6
0EllvDLhYb2kTmbAWuU8pdh5svQSkfkT1osp60Wjx2JiEgOZSiMGWytl0Ipa
WwMlc5wX6WxYhop0FhhKTyxjNLjciJAq3Ccm5WpXHCp+W0xb7bO3fXm2ibfw
robqDByeCpyxdSjhI+xjoieWfI+NGM1NedLCT0JCAzAk6JwF5D0Ja/wjgz1v
uY1sWQyJ1YV3K/Se2B2wFGCtcO9wWKxxm2bpEVGkK8LXxaLKLbkpDMmK1HI8
ZvfwiLE0ACFYEayYLVnxkcha2Ba+Ptq4hA69c48EGVmdc58pgMYUvgzgKtap
hoHuAtiUhPwsROklDokCiZH4IMDGxxZ7XQ7kpUPgUkwE68aKAoauSIZInGTk
D7YAvAF44DAKKgLmb1jzN6RsrjZ5KzpMDAOKxIBlzb9WCtgNRg30o028ESQk
LMnXoeOzjOMmfA3lbeS6ZszvdeFCFtD6aK6zWZ3uel+7YXG7tmu6HUW2tKfc
AwE9mxrmasB5CRGiH5yNVxbG+NsTtKFT7P8IPoFlAXEZelzAXtXclXAXpXdO
ZGQNgOT6LWv1tQ/MdY7mwzRrDFLVkNAgAM/F6GpHpbTwzEham2WuIk+XGgp6
xdwuCK82uZVuAEedo6eJds/P2PQt6KkTqmbNziotg9ehgJGZx6ZWMEdabOQU
gff0NGSNsa1kgZVHq5W3+gZPHFs+pSuURkFFMTLBTjOSHe8u8XubxO7ZMehC
PP19QGmXzsgxkaNfrABIy0Kb+R0RHOjOjdgxESa6L1lmPW3Lke0LPuZz5qLP
exhLN/WqNT/rY1hT+WDmgnKTc0j10vJe2FvY0UFH9QfHHQrGg8MjWqPjvWSK
jBIpH3tgHUVmURLuCDa00ddThByx7BVbW8jF50T9XsEuqN/rUfq7e0e59lA9
IpAYgUt6Qt6Dc34NLjKopdy+NPXJbI28AuwGsy/aBQSPvTpc1DBQC3ZPFKJG
29I2WTOHDbFW6BdJOrTT5VmNLnTQSpJDHrYhv6nN8ZBRQqsI5dcC5YDX9wYu
WEyb62M6u1dFiqMIOYLHCdDvQroLwhgPRLbL9sCI8yk1UyjfJmlm9UmK9jYk
sGQr2GsFX3Y/m3F6PQS+alXFLnwKqkYxPFhpCwFjV5O/wWWrXXIYe+rpFRu9
+JaaIWsaT+OIDbGBNks+EDw9STk0dFxZg7YrBqQTGE+kpN5R5WZtCe9G2Fxs
irwbyuBWWbdBOMrEQrfTC1cHbiKWUlnNRhUWYJ7CzMlaWDy00vn48poIaY7j
BVcuF8YDI8qSDw/ZBQlsjE3wdD56P1J3J6f9Z8+bDhhBpeBVkBqzjlQpF4/O
vYM5P+0QSYCOAjJgKtNEzwoujhAqBuFd9S+/C0P1/bvR3R9VGP4h4J8jeJmf
Kgaj3gC59FxIhuXRBJFSrObMSKK69OAPC2SUjPH74L9/66epSPfUy09/y7PB
lmf7rVX6GLGvDtShOlKv1bF682ue1et8FX7mf/VCH/H/HUn/W9X7uXeI31dS
EL4w2Qy6Qe9vkBXkD2Arj7/OzdT+3Lz/chQ1K21h4K/5rJ3t5YcbvbAjqaX9
f5/mbN3PpKj7xRf6fG7/doN4GqpXay5O+kjf7pCHueMXtRIR3GDw5Z0oA7em
jskIpkn2xOfLiCbSiA1vuFvJrLgfgNldqXHIYhUhbF/WQFSjEAg8wCkp1/xW
FZI1Urrqdu5yihryuF24jVyFhSdNA2UmOZgPoGuNJlMXdaTOIoCKVyx8EFjz
9mmFSDTXD0iiS7UqRxMbhb/KNc0ZQVHLdum5XYIkzxcw16i6vXKENde6vHsr
zMQWKKGUhJT5ziXngHuIrQ6Q30LqvgJvKTDkIDpBvr5YBesaOFAHGNGWEM4w
GKpzoWhiENyLajYTqbXq6Kw0lNLZRmt22SHBHR3tBdyULgm3Ucgo23W+doOE
um5SOaAAvUEzFqEqN+EvXZa5nQBTkUBu65LiqvzuGe7hZF2PSBCTaRXWyHbX
DHEGCvBgfZ0A35FiqWva6cJODSVGgjz87RP1TsLu0yvA4K0tTM5cJHugezSm
mXl04R6vR+83Vgp2b2/ehXh3825Porivvu4fPz8T6TCEByNq0074xcLqSm7B
UHqtdVOXhNatpgXJSmoZkRGs2gPBmg6wxjFlEmBkRRy4lecrLr9tHmk8ptMQ
a2QrAI/XXU4dQoFfOJogLlG9NiYjNG0eg3UY2/3c+P/5sf8z474KvojTxyIf
+x97+C8vHj6e3CL5+tiW0WsKmm+R+DHr+cNB9NLFVVJxtPz45SiBBdYY771g
vF/1+aKUfNaHKfkisf1Ti0hNmm5M6N++yK+i5Ivw5POl85k4pXEZDUZZcwyE
S2AJwzaE4H6JB7x8e6TidI3iFaIC9+gmpnZNPW5pIc4RUPFBwFckBIHIM/Jo
XeQ0PjPPZRk7y5yvmXLuJXGKg2nxINTAc7GVUij14coDpXYTsuketF18V42r
PPc9fu6+Yf2jAy7PdmpUVLRLJb5qWy2ow2Ni8eC8fcMaLAF7dbGUMF+UdsIJ
kcUFno9+pmSVH2sN5me7J9hsDyryMWx/vgq3fDCopVW9LXqJM60P6r8cRMdd
HzR4OYjY8LFWGz5JrTXXrigstanaHSKfAhWkREHtNElQd5+sndaAogZoLL22
bTO3avikRj6+1SXCYqVXvic1qesC2Kug6rZOAO2oXBCVwfrm9aWGqNYKhTcJ
92CnSpShTrULug9G0pamlcnoyg6o8mGgPmPqowJjiRqY+XLA5t6pzTASotql
Qo2i3zatGjjChxeO02It/LXnkXMDQKO5c4UYAa3jadiVgkXlObaxqtQ/o7kF
i6QexYUTboQosfJtdcDdp6f1Cn3x/LwHPmyELeLH/kA4uFG1EBvaYGt9rYP2
1c0Msf4V1KovuxT1OI8T2ymSznOi1idLYBEWYSbJPSGLNEVDzotNHnIxV5qT
rcoxpzDUIVXN5qQz5NoKLnlvXslhiE0l8RW7iRcjzrfEZYhuNCme1GKpHcBt
fsqs6ss+tnWHqkWBcDCRakMN8RpPrVcdUsdavCxZpLuD/9wV//OV2t+Tx3uy
VH3JRFbk4h0xEc4+d6nXKjIy5o53sLIfL9iV+3x0Ny2t28B8S2HQ6+93Xrad
HylvqUeLpxxTz/3eUvkTgqvyjO+iSfrWqjGTEVDbufJ+YsOXONIyD9NtvrXt
6It4lM9Ec14k7VCBcQHjh4ikV+27PVuXkD0lNMzI65Qv6/RrdVbYoa/Hcpou
Yo85SHIRl5fyM7bcmZJOrG8dyrC1ou6ev4x3w45AeCMqTClHo8CbraLO2tj1
MjHNoS4Bs6jwtxylO9lZMdAzjXs7L5bYbPM4IaJpEjWXMah11DSlKU2R7pNv
HpnEPFCXbluhm3nS0LBK25mOoA74vAEMGxkpbwHvzt/qbeatDuiaEIP6ih95
3dx4bsVqV+zVu2PYfUw3PhM309wql9QZ8SOAPducnDUZxwmi2xSCfnnTYhgE
6p9V+97q5sVH320ShENmwwyrQxxfCW+17Nr3HAmy2ch8QztgA3ohDflaPNRE
L+TSwKqjRN6ryqW3hpw+9f/covC9bo+sEImEo746r+4tdeCna/x/0TuBMOp6
SqulA3/waEDWbnOVBE87QV3m8B5ni3FQnaezukuJQGiTGKFc+oqtHeTGbvHy
woET+dwaYABqKJN4bMyXXvENpnV1esXejcr9L15ypk1FeG5MmZkl0a5uYcRU
u1oNkPskLjIxoecGKQaMFPmO3THVKDzWITLpKvAZZO3yobqmchip4iLhu5TU
/4kEufi25c7T0z/RJfHn5x1WGS5h0BKrft3Le2Ns0DvUyNhZ6Rm3OApYH9fD
SGo0AAqPkzQTXm9MUJsTXkuhhzosD0fqum56qJsWoxAniLP+RlZTCoOG+zpG
zTxD/wqitvExbee7vaIdARXNKIrkLuHXRS2P5ZCQN8+gHEy9p1s7L1IzEDU1
zMo1DD7chr/XHxOGZu7wMlzNfLl6IxlB05FLim93IoWYS1AZTBpD+7j7u72o
JbWI38w4Ky1+Zt3GRsHf22idj3/xucuv4OLWHGb9MechpDFYYrylAPZ3OQgL
HUV0qTYx8YxRHFmnzu753H/VRbWs7q2605m+16yfFM/4mh1dN28utfvr3u0C
rU/9CMXfWoIsVK7L8ZCSleaf+9CdVu64qQu6h/c9XWMdKnVag8axG13jj5sz
dXp3catOx6O3/MfvuXHP/xACx/xwcx6smnfrS9G/kRG4/BegM74U8efbq/d8
1aQodbpYfSvU9e2/fnIhOP18uSjVh7tx/Z3xiC39+uSD5/BfsXp3ORp/cp0V
ouCOLPUdpcB8fv3QuhNEb9gsPk1QA+vjFbsYD76Iqz54yFL/B2NCaduGOQAA

-->

</rfc>

