<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-wilaw-moq-cmsf-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title>CMSF- a CMAF compliant implementation of MOQT Streaming Format</title>
    <seriesInfo name="Internet-Draft" value="draft-wilaw-moq-cmsf-00"/>
    <author initials="W." surname="Law" fullname="Will Law">
      <organization>Akamai</organization>
      <address>
        <email>wilaw@akamai.com</email>
      </address>
    </author>
    <date year="2025" month="December" day="01"/>
    <area>Web and Internet Transport</area>
    <workgroup>Media Over QUIC</workgroup>
    <keyword>moq</keyword>
    <keyword>moqt</keyword>
    <keyword>MSF</keyword>
    <keyword>CMAF</keyword>
    <abstract>
      <?line 50?>

<t>This document updates <xref target="MSF"/> by defining a new optional feature for the streaming format.
It specifies the syntax and semantics for adding CMAF-packaged media <xref target="CMAF"/> to MSF.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://wilaw.github.io/cmsf/draft-wilaw-moq-cmsf.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-wilaw-moq-cmsf/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Media Over QUIC Working Group mailing list (<eref target="mailto:moq@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/moq/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/moq/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/wilaw/cmsf"/>.</t>
    </note>
  </front>
  <middle>
    <?line 56?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>CMAF compliant MOQT Streaming Format (CMSF) is a media format designed to deliver CMAF <xref target="CMAF"/> and
LOC [LOC] compliant media content over MOQ Transport (MOQT) <xref target="MoQTransport"/>. CMSF extends
MSF and retains all the scope, capabilities and features of MSF including the catalog
format, timeline, ABR switching and LOC support. MSF is targeted at real-time and
interactive levels of live latency, as well as VOD content.</t>
      <t>This document describes version 1 of the CMSF streaming format.</t>
    </section>
    <section anchor="msf-extension">
      <name>MSF Extension</name>
      <t>All of the specifications, requirements, and terminology defined in <xref target="MSF"/> apply to
implementations of this extension unless explicitly noted otherwise in this document.</t>
    </section>
    <section anchor="cmaf-packaging">
      <name>CMAF Packaging</name>
      <section anchor="initialization-headers">
        <name>Initialization headers</name>
        <t>A CMAF header is a sequence of CMAF constrained ISO BMFF boxes that do not reference any
media samples, but are associated with a CMAF track and are necessary for initializing
the decoding of the subsequent CMAF fragments.</t>
        <t>The header for a given MOQT Track <bcp14>MUST</bcp14> be packaged by encoding the header using <xref target="BASE64"/>
and then inserting that payload as the value of the Initialization data "initData" field
in the catalog entry for that Track.</t>
      </section>
      <section anchor="switching-sets-and-tracks">
        <name>Switching sets and tracks</name>
        <t>This specification defines a direct mapping between CMAF Tracks ( <xref target="CMAF"/> Sect 3.2.1) and
MOQT tracks (<xref target="MoQTransport"/> Sect 2.3).</t>
        <t>CMAF switching sets are a set of one or more CMAF tracks (3.2.1), where each track is an
alternative encoding of the same source content and are constrained to enable seamless
track switching (3.3.9).</t>
        <t>Each CMAF track in a switching set <bcp14>MUST</bcp14> be transmitted as a separate MOQT Track. The
catalog entry for each of these tracks in the switching set <bcp14>MUST</bcp14> carry a Alternate group
(altGroup) key with a common value.</t>
        <t>The MOQT Group numbers within these switching set tracks <bcp14>MUST</bcp14> be media time-aligned.
Mandating the track being media time-aligned requires that the presentation time of the
first media sample contained within the first MOQT Object of each MOQT Group is identical.</t>
      </section>
      <section anchor="object-packaging">
        <name>Object Packaging</name>
        <t>The payload of each Object is subject to the following requirements:</t>
        <ul spacing="normal">
          <li>
            <t><bcp14>MUST</bcp14> contain at least one Movie Fragment Box (moof) followed by a Media Data
Box (mdat). This is equivalent to requiring that each Object hold at least one CMAF
Chunk. The Media Fragment Box (moof) <bcp14>MUST</bcp14> contain a Movie Fragment Header Box
(mfhd) and Track Box (trak) with a Track ID (track_ID) matching a Track Box in the
initialization fragment.</t>
          </li>
          <li>
            <t><bcp14>MAY</bcp14> contain multiple successive CMAF Chunks.</t>
          </li>
          <li>
            <t><bcp14>MUST</bcp14> contain a single [ISOBMFF] track.</t>
          </li>
          <li>
            <t><bcp14>MUST</bcp14> contain media content encoded in decode order.</t>
          </li>
        </ul>
      </section>
      <section anchor="group-packaging">
        <name>Group Packaging</name>
        <t>Each MOQT Group</t>
        <ul spacing="normal">
          <li>
            <t><bcp14>MUST</bcp14> begin with an Object containing a stream access point (SAP type 1 or 2).</t>
          </li>
          <li>
            <t><bcp14>MUST</bcp14> contain one or more contiguous Groups of Pictures (GOPs).</t>
          </li>
          <li>
            <t>The Group boundary <bcp14>MUST</bcp14> align with a CMAF Fragment boundary. CMAF Fragments and CMAF
Chunks <bcp14>MUST</bcp14> not span Groups.</t>
          </li>
        </ul>
      </section>
      <section anchor="catalog-description">
        <name>Catalog description</name>
        <section anchor="cmaf-packaging-type">
          <name>CMAF packaging type</name>
          <t>This specification extends the allowed packaging values defined in <xref target="MSF"/>
to include one new entry, as defined in Table 1 below:</t>
          <table>
            <thead>
              <tr>
                <th align="left">Name</th>
                <th align="left">Value</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">CMAF</td>
                <td align="left">cmaf</td>
                <td align="left">This RFC</td>
              </tr>
            </tbody>
          </table>
          <t>Every Track entry in a CMSF catalog carrying CMAF-packaged media data <bcp14>MUST</bcp14> declare a
"packaging" type value of "cmaf".</t>
        </section>
        <section anchor="max-sap-starting-types">
          <name>Max SAP starting types</name>
          <t>This specification adds two track-level catalog fields, as defined in Table 2 below:</t>
          <table>
            <thead>
              <tr>
                <th align="left">Field</th>
                <th align="left">Name</th>
                <th align="left">Definition</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">Max Group SAP starting type</td>
                <td align="left">maxGrpSapStartingType</td>
                <td align="left">
                  <xref target="maxgrpsapstartingtype"/></td>
              </tr>
              <tr>
                <td align="left">Max Object SAP starting type</td>
                <td align="left">maxObjSapStartingType</td>
                <td align="left">
                  <xref target="maxobjsapstartingtype"/></td>
              </tr>
            </tbody>
          </table>
          <section anchor="maxgrpsapstartingtype">
            <name>Max Group SAP starting type</name>
            <t>Location: T    Required: Optional   JSON Type: Number</t>
            <t>A number indicating the maximum SAP type the MOQT Groups in the track start with.</t>
          </section>
          <section anchor="maxobjsapstartingtype">
            <name>Max Object SAP starting type</name>
            <t>Location: T    Required: Optional   JSON Type: Number</t>
            <t>A number indicating the maximum SAP type the MOQT Objects in the track start with.</t>
          </section>
        </section>
      </section>
      <section anchor="event-timelines">
        <name>Event Timelines</name>
        <section anchor="saptypetimeline">
          <name>SAP Type timeline</name>
          <t>CMSF defines a special instance of an Event Timeline track, termed the SAP Type timeline
track. Its purpose is to convey information about the distribution of Stream Access Point
types and their associated Earlist Presentation Times.</t>
          <t>In the catalog, the SAP-type timeline track <bcp14>MUST</bcp14> include a 'packaging' value of 'eventtimeline"
and <bcp14>MUST</bcp14> include an 'eventType' value of 'org.ietf.moq.cmsf.sap'.</t>
          <t>In the SAP Type timeline JSON payload:</t>
          <ul spacing="normal">
            <li>
              <t>The index reference <bcp14>MUST</bcp14> be 'l' for Location</t>
            </li>
            <li>
              <t>The data field is a JSON Array containing two integers. The first integer defines SAP type
with an allowed value of 0,1,2 or 3. The value 0 indicates that the Object does not start
with an ISOBMFF stream access point. The value equal to 1, 2, or 3 indicates that the Object
begins with a stream access point of SAP type 1, 2, or 3, respectively. When the Object is
the first Object in the Group, the value <bcp14>MUST</bcp14> be equal to 1 or 2. The second integer defines
the earliest media presentation timestamp, rounded to the nearest millisecond, of all media
samples in the Object defined by the Location of that record.</t>
            </li>
          </ul>
        </section>
        <section anchor="sap-type-timeline-track-example">
          <name>SAP-type timeline track example</name>
          <t>This shows an example of 30-fps HEVC-encoded content, in which each 4s Group beings with
SAP-type 2 (i.e., the first picture in the Group is an IDR picture, while there may be one or more
pictures in the Group following the IDR picture in decoding order but preceding it in output
order). After 2 seconds in each Group, there is a SAP-type 3, i.e., a CRA picture, which
is associated with one or more Random Access Skipped
Leading (RASL) pictures. A small buffer of frames (10 frames at 30 fps) is skipped/discarded
(RASL pictures) when the streaming session starts from the SAP-type 3 location. In this example,
the EPT is the presentation time of the first picture after the RASL pictures in decoding order;
all pictures after the RASL pictures can be fully correctly decoded and are thus presentable
when the streaming session starts from the SAP-type 3 location. Note that if the streaming session
starts from the start of the Group, then these RASL pictures can be fully correctly decoded and are
thus presentable.</t>
          <sourcecode type="json"><![CDATA[
[
    {
        "l": [0,0],
        "data": [2,0]
    },
    {
        "l": [0,60],
        "data": [3,2100]
    },
    {
        "l": [1,0],
        "data": [2,4000]
    },
    {
        "l": [1,60],
        "data": [3,6100]
    }
]
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="catalog-examples">
      <name>Catalog Examples</name>
      <t>The following section provides non-normative JSON examples of various catalogs
compliant with this draft.</t>
      <section anchor="simulcast-video-tracks-3-alternate-video-qualities-along-with-audio">
        <name>Simulcast video tracks - 3 alternate video qualities along with audio</name>
        <t>This example shows catalog for a media producer capable of sending 3
time-aligned video tracks for high definition, low definition and medium
definition video qualities, along with an audio track.</t>
        <sourcecode type="json"><![CDATA[
{
  "version": 1,
  "generatedAt": 1746104606044,
  "tracks":[
    {
      "name": "hd",
      "renderGroup": 1,
      "packaging": "cmaf",
      "isLive": true,
      "initData": "AAAAIGZ0eXBpc281AAA...AAAAAAAAAAAAA",
      "role": "video",
      "codec":"avc1.640028",
      "width":1920,
      "height":1080,
      "bitrate":5000000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "md",
      "renderGroup": 1,
      "packaging": "cmaf",
      "isLive": true,
      "initData": "AAAAHGZ0eXBpc281AAA...AAAAAAAAAAAAAA",
      "role": "video",
      "codec":"avc1.64001e",
      "width":720,
      "height":640,
      "bitrate":3000000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "sd",
      "renderGroup": 1,
      "packaging": "cmaf",
      "isLive": true,
      "initData": "AAAAHGZ0eXBpc281AAA...AAAAAAAAAAAAAA",
      "role": "video",
      "codec":"avc1.64000d",
      "width":192,
      "height":144,
      "bitrate":500000,
      "framerate":30,
      "altGroup":1
    },
    {
      "name": "audio",
      "renderGroup": 1,
      "packaging": "cmaf",
      "isLive": true,
      "initData": "AAAAHGZ0eXBpc281AAA...AAAAAAAAAAAAAA",
      "role": "audio",
      "codec":"mp4a.40.5",
      "samplerate":48000,
      "channelConfig":"2",
      "bitrate":67071
    }
   ]
}
]]></sourcecode>
      </section>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" 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>
      <?line -18?>

</section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="MoQTransport">
        <front>
          <title>Media over QUIC Transport</title>
          <author fullname="Luke Curley" initials="L." surname="Curley">
            <organization>Discord</organization>
          </author>
          <author fullname="Kirill Pugin" initials="K." surname="Pugin">
            <organization>Meta</organization>
          </author>
          <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
            <organization>Cisco</organization>
          </author>
          <author fullname="Victor Vasiliev" initials="V." surname="Vasiliev">
            <organization>Google</organization>
          </author>
          <author fullname="Ian Swett" initials="I." surname="Swett">
            <organization>Google</organization>
          </author>
          <date day="3" month="March" year="2025"/>
          <abstract>
            <t>   This document defines the core behavior for Media over QUIC Transport
   (MOQT), a media transport protocol designed to operate over QUIC and
   WebTransport, which have similar functionality.  MOQT allows a
   producer of media to publish data and have it consumed via
   subscription by a multiplicity of endpoints.  It supports
   intermediate content distribution networks and is designed for high
   scale and low latency distribution.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-moq-transport-10"/>
      </reference>
      <reference anchor="MSF">
        <front>
          <title>WARP Streaming Format</title>
          <author fullname="Will Law" initials="W." surname="Law">
            <organization>Akamai</organization>
          </author>
          <author fullname="Luke Curley" initials="L." surname="Curley">
            <organization>Twitch</organization>
          </author>
          <author fullname="Victor Vasiliev" initials="V." surname="Vasiliev">
            <organization>Google</organization>
          </author>
          <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
            <organization>Cisco</organization>
          </author>
          <author fullname="Kirill Pugin" initials="K." surname="Pugin">
            <organization>Meta</organization>
          </author>
          <date day="22" month="July" year="2025"/>
          <abstract>
            <t>   This document specifies the WARP Streaming Format, designed to
   operate on Media Over QUIC Transport.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-moq-warp-01"/>
      </reference>
      <reference anchor="CMAF">
        <front>
          <title>Information technology — Multimedia application format (MPEG-A) — Part 19: Common media application format (CMAF) for segmented media</title>
          <author initials="I. O. for" surname="Standardization" fullname="International Organization for Standardization">
            <organization>ISO</organization>
          </author>
          <date year="2021" month="October"/>
        </front>
      </reference>
      <reference anchor="BASE64">
        <front>
          <title>The Base16, Base32, and Base64 Data Encodings</title>
          <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
          <date month="October" year="2006"/>
          <abstract>
            <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4648"/>
        <seriesInfo name="DOI" value="10.17487/RFC4648"/>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <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">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <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>
    <?line 318?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Va63LbyJX+30/RgX/YSpEQKWk8Hm5utC62UpKpETXjnbhU
qSbQJDECAQwaEM14PLUPsQ+QZ8mj7JPsd053g+BFTlWSSu2yakbkQffpc/nO
reFutyuqpEr1QAan1+OLrlTy9Hp4IaN8UaSJyiqZ4Ite6KxSVZJnMp/K69G3
d3JclVotkmwmL/JyoapARKrSs7xcDWSSTXMh4jzK1AKc41JNq+4ySdWyu8h/
6kYLM+32esLUk0ViDLhWqwLrLs/vLkRWLya6HIgY3AYiyjOjM1ObgazKWovH
gTwWCidD3vd6IlUWy8us0mWmK3lXqswUeQlZlnn5MCvzusC6ax0nSo4edSm/
/e7yNBAPeoXn8UDIroQ87k9Ff2EC+kMmEI86qyGClE8yktIKHrzHcWSKN7SS
6AuVpKCD7R8SXU3DvJwRWZXRHOR5VRVmcHhIq4iUPOrQLzskwuGkzJdGH2L/
Ie2bJdW8nmAnG/GQDEjkFDYyVYshPw7t6jDJeeHhPvOH82qRBkKouprnJSnZ
xX8SnoOl34fySi35t3Vg8D5JU6IFTISUKkv+wngYyOGDgh78QFu1+ag/KKaH
AJIQGUMEatJJ1/m3jafg9O5ZaCUkC7CAlX/a7fdo/fhiIPetW6qywHNy1oDP
X2tDn66T3uKDpVWpHLWEl9O8BJABIlXGjuY2s5bYOx4xwcfIJZDNqmBzpaN5
lqf5bCX/57/+W17XaZUsGCKqQOxEzRFYL19c35y/6Q4PeOmNKivZ/2bQnEWf
03yxwPqnOZCeByyy0TMKSB3b1dYrHDDyqHfUt2Z7PRyfvzwZyNuL05OXJ6+E
EIkXnvwgwjAUottFxE8MLB5VQtzNEyMRtjVxl3VBLI38AAfcy8lKxnqaZARz
JTO9lHnhTDrVqqpLzaJVcy1NkxrseaG4rKQpdJRME/DjJSvkk48cvgaoyaok
MrxfxTFtJF27hYoe1MxrKT8Q8V5WOSECsrPwiySOUy3EM3Jzmcd1xE4UW0ls
b8oik45hUiit3BnO1rE2ySzDyTgs1mlCIc8cnQyQW1yNTuUH/O++dYxlgqRV
kQFz2oaT14kJMIAgBzBpKwbuQ0lySP0Ru2Ij6DsZptSVQjxKhdhjm0V5oTsy
UoWaJGlSkS1pnTO/4dSMvUkWpTVbkXYBRAoYFVazjiSMpkkGRsPXt9Iskwr5
h3wKTqSSqQsSKrSs4C1VzjRBDWaB+dIuMWADJBRXwA2sI1P9qFOWIOWfAE4W
rTpSGbnUkB9/vx+decuE21CDvaMymUAHmIwKguwTL5KfTbOLKDicHpyTzWiD
GOIUt8VBzYaP6UDsn+qk5BqGX6QoBAc3G7uMauiXZA7pFHsreF5sVj5j2UNs
7Q+VdZZqQwSKVqSIlcxyslUOMcplYjRxrdqqsuQMpRtGN3QChdALh6rUJ6a5
VjEsIYZ2rf1pgWqgDYyrSRyH8owCmJVAvpKvry8u5CT/yKFGYM5JKlhhqkve
qLKVsEg1ilSEUSZ1heKER8bkUaJIByBj7rsByg8PbDlalOkIWqtyxRGbeMlJ
FTJ/rKOc4efdUU+szJVlNi0Vpy/DMNBeOY5+VDqUXRuud3zo9XfjOznRskkG
SETQIm8A7rbXhggfbNa7F+zlOVghgnRZ2cUwRqFWaa5iAiRtflRprb2gWz5A
9lMyIPXO8C2QSF4pob4dVhClcnZg9ixzyB4dN6FldGUjlc1oLPY3QOpASO6N
gdQImQQopL0TXS011GDLMXcjX/g0NKaVx+FR2D/giGSzVW7RZo6xa4/C44PQ
JUezJR95n76SNfIMRinRFZW6BQAwtYd15BL41lKraO6wQdDMhEpdqUUOaJzk
YYBiLE1el0Cgz5AeUW0II+XqTE1SLEbMU3wJe8RaYIhxHH5DmpyTBC2Iwjtq
U7MGQNxVLJKKc5kNpEKVgHoLbaEEIMWub1lRq4fR3hgOCXtOi1SJjUoOnTm0
bSHFC9iHW8QDiR7UR1hkCz9D0YUES8Qrpe2HDS+2J5rtM508XlEb2pSmuwAz
lbFQXFOPU/mQsbaaaPq9u9rnS5c+aEOBX80EwAXAGkNMk9L4smeTCfvWenIt
srTrWK3R5EeCIhiwVVuqAkNJrKkXUKmNIbe2lSrJOj6GPQu3ioKqtl+BIT41
T9N8SVq2SwB6n187P1lRqbSlWkFAwv11/phoeeGSlHydf5QvFnk+PXDsbApS
0k4DlBqo2eJVMPEBQYgUQVXAkXAqMYE8VoImD7UFn+dpvCkDzx9oCed1ZjHp
Ttsn1aYm2+K/tdkR68HvxWI6jzlVuOTKbICGhwMPRku/PGNy9PDny7MD5CLf
I7S2WccKuc7/rlt1J4dk5OEPjWQLao8JH6aOqHxQiuDAZSVNuOMTSQkd6z+g
plFJu7ew3Vm42XNx1rHVnOsQ5TEYwMLJwqyFpvNNBDbAmGg8dybJvJvcgdYQ
tiORinWRRY5mSL4YD294IqTupZRHBzuytvMq0ZJZndfGHs79xU0S2V7uxZvR
jWEG5H0r+CSvaVJZWZ4crRtVunG6Xxhu0m0RamPLJQ1qD0wBTa0g1linLgva
3qywbfWzZ657KbwRWeF9Jc21sxyIygXOehdnO7PTfAlEiu1fNRuL5gxOw9xK
tlbfcYXow1PgjIj+Wb6j+rLx+Rn/fc8Fvk3B57ZphTxd/Dz47c5nl7ZvFdNx
Pptl6/xooaabFDYURrKtlYAiOt+Viy9beDgIuP31BYnrylPjEbcr7E4AP+Vy
LoLG4IEFZtPvBCRaEFqPXmMUI+waNPuV9+nePgXjGTy6zG0sdrntb8TjBsns
99RRy1MXtE7u/8BDu45suY4/ZzyIskBfcN/fd9vTD5xPyTA29nbMA4EW6uOb
shirYuwe3BEdDz59wqNZWRhV+D205fNn6Zm6lLLDlZni4VNM88mP+5iSF599
UdpPz/aLJK7yyF3k3NnQ4EIZD+TIj/dS/nE8eifv+KrrHbcjAoOJbUzg4ZjB
4VoLnJIs6oVsUmG10c40XZNr6UgUzmFhS4enjGOV2GOCf58SVrQvayERykjC
d27QNjbGiBe70g/g0AZ6EHtP+Sw42tezAMcehMcMUyk38iFLb/K3QnR4ptU8
9OyeZTvoUF5C9KIui5wmU0NtCarQo17JpHWvpVA+bNsXJyhzCWZDd/FrL1Dk
0Ba9Gyp6glOFdONWUrYnyHNVpuAgb9rdI4lNFeZyY47qeLm71YaNqvUM6MuC
ks+brPZ8ndCea7KK3xjwALi5L3NryDLtjXk5s7evi/ynkC9H4ZfnaxF3PcdQ
cl0od5NUo4Eh/bE1Zft2/Hn6nGcIj1G3nNM1Z0w71jPPYVmqVbvRoFRL9ywz
jAC2EbSdtKM1WPFIRWH3XYuvuY2ivU6/c0Ttx7HlZB/0PPjb/b6LwDgHkZsD
QniLt2vJ9nVBbd4IQ6AXKOt35FGHj376NLDntsv4nmZfi0UgbJqshild8VCs
0NyZout5T4N/S4/E0FV9YzxPtWs4L3VatwHecWvpuZuzihk0lVm8bX/HXhPg
dTMQ7UxNMOMCR5XUntlJl3Zl2MabkhThwvw7HOlpahmBu7uo8TJ7/7gqi3mE
qB5hdjjj+7oI3W/YJKC9waU/Mm9X7ef5kqLZU4nVca87ReJ+e/79ade3167d
7pBAy3mCLpoHmhPjW1WaLa0nRXPwkXyRhDrstFxR2H53wxf2LgEzyK1/TPcN
ScppuKTsvCL3tHppUfi2eYPPevzj2501v2Y64OsJmg/4Agz+ijTTEkYH0mBR
V4IXYK4bTpFioYR1EZ/FSq8BVGoby43GQKbVGI3c7XBDnWguaO3WfVt7QLhF
CsubbDt+SIpCx+IKAx3fgdwOx1cHniWSw1CaBUFmUk+RgshxGMUWNEr0e/4r
MHGMH4XhS29jWR4izaOzhFsFM214HtA1T7Z1pW80v7GzKcGAMUTcyN3HMnU4
RL3J/I0po6nD94PnN3dcfL5wr7CFDsWWJ/qGfLtu/A9BFmieP7UvAryAoGmd
ppRtS7pxS1duYIybW6lqjtnMi4gmVvyz5niXV9pGZjLdz0ds87G9hbPKGmn+
Iugf0Uts64UE8csvv/xocPwHfpX0qXkxFaTBQH7odXr3nTWNSheRj0Bm6ufO
E9te7t133Dnq9768tf/UiSe9v7vzqUNfrg8V96Sx4Lt4N7ycW4gae8W0Th1G
8xsl2Ct/TGKuh1m3eZ9py7aDN0/wj6pMaKZ3jY0R67dDHOH2bQC9yKRXWJSX
0WqmEd38EP/c3+Z1gRzV3B/aR1SQ3HufNIdstlDWcZK7Fyo+a9s03sxlfLPu
axK9I0NU8Gskm+CBAw6hY7FxDbghDvGYJ7O5ewlIJukA2cvWb8YXnVIvRIu6
JXpnQ/bMiu+vdhocklcD9y4I3uuTQ4OZzjRd2MbDimhfn8CjJy97L3snJ/zc
ihoMNkEc0FvggF6Sx4HHRYAWDenCvq537Jm+npcHbkRuHiXmCg4P7D9EWFP9
6wGsH+Jz+eZPPf2fr4vo6FUfP8MwHLY/LQnylKVi86zJFKlRMAjUY9QPXwLt
R6/WD5dJXM2DQf+bo15DQ9M9m8Me/d6rNXGSVGSoYPBVjz/NA64D9tHxmuqv
pcFlX2g1Flz8Oyz49ssW/AdM2Nc7Jvx6jwWxdNeAx/9SA5r/nwbsxfswuAtB
G4f7EPgvsh8ni/+TJtySzJtwUZyo8KQXfrV+ZFt5a4KTV23bRHOVZTo9zbNp
AtGDo2DXnC+/7n3tbET/vxef15WMRvnMvqqmVLy+JXNFjd85oU8yMqAZJ+jY
v/LdiL/fnn/73eXt+Rl9H78dXl01X4RbMX47+u7qbP1tvfN0dH19/u7MbgZV
bpBEcD38IbCv3oPRzd3l6N3wKth5N26brpxaGP63BWhR7Ms64f99AF8ovj69
+dtf+yfy06df3V6cHvX733z+7H68QlHAD+rT7Gl5hv7H/kTDtBIKDa8q+Wo1
pYvLIkGJtFeWVDPpxXtJ/dCvP5Bl7gfyN5Oo6J/8zhFI4Q2it9kGkW22S9nZ
bI24h7TnmMaaG/QtS2/KO/xh47e3e4v4m9/zHNjtv/r97wRjaKyjukyqFYHJ
ICuUyuNndDZqnvLSy+G74e6yDX/OFbVLdqXiNsr4f7czQYgSl2H0kOXLVMf2
DYX4NLBXcjr+bTCFa3Tw2R2umpVw0P8CuPWa17goAAA=

-->

</rfc>
