<?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.21 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-cenzano-moq-media-interop-01" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->
  <front>
    <title abbrev="moq-mi">MoQ Media Interop</title>
    <seriesInfo name="Internet-Draft" value="draft-cenzano-moq-media-interop-01"/>
    <author fullname="Jordi Cenzano-Ferret">
      <organization>Meta</organization>
      <address>
        <email>jcenzano@meta.com</email>
      </address>
    </author>
    <author fullname="Alan Frindell">
      <organization>Meta</organization>
      <address>
        <email>afrind@meta.com</email>
      </address>
    </author>
    <date year="2024" month="December" day="28"/>
    <area>Web and Internet Transport</area>
    <workgroup>Media Over QUIC</workgroup>
    <keyword>Media over QUIC</keyword>
    <abstract>
      <?line 39?>

<t>This protocol can be used to send and receive video and audio over Media over
QUIC Transport [MOQT].</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://afrind.github.io/draft-cenzano-media-interop/draft-cenzano-moq-media-interop.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-cenzano-moq-media-interop/"/>.
      </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/afrind/draft-cenzano-media-interop"/>.</t>
    </note>
  </front>
  <middle>
    <?line 44?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This protocol specifies a simple mechanism for sending media (video and audio)
over MOQT for both live-streaming and VC style use cases.  The protocol is
flexible in order to support this range of use cases.</t>
      <t>The following parameters can be updated in the middle of a the track (ex: frame
rate, resolution, codec, etc)</t>
      <t>The protocol defines a low overhead packager (not LoC [loc], and is extensible
to other formats such as FMP4.</t>
    </section>
    <section anchor="protocol-operation">
      <name>Protocol Operation</name>
      <section anchor="track-names">
        <name>Track Names</name>
        <t>The publisher selects a namespace of their choosing, and sends an ANNOUNCE
message for this namespace.</t>
        <t>Within the publisher namespace the publisher will offer media tracks named as
<tt>videoX</tt> and <tt>audioX</tt> where X will be an integer starting at 0.</t>
        <t>So in case the publisher issues 2 audio tracks and 1 video track, the track
names available will be <tt>video0</tt>, <tt>audio0</tt>, and <tt>audio1</tt>.</t>
        <t>The subscriber will consider all of those tracks belonging to the same
namespace as part of the same synchronization group (timestamps aligned to the
same timeline).</t>
      </section>
      <section anchor="mapping-tracks-to-moqt-object-model">
        <name>Mapping Tracks to MoQT Object Model</name>
        <t>For the video track, the publisher begins a new group at the start of each IDR
(so object 0 will be always an IDR Keyframe), and each group contains a single
subgroup.  Each object has the format described in <xref target="object-format"/>.</t>
        <t>For the audio track, the publisher begins a new group with each audio object,
and each group contains a single subgroup.  Each object has the format described
in <xref target="object-format"/>.</t>
        <t>TODO: Datagram forwarding preference could be used, but has problems if audio
frame does not fit in a single UDP payload.</t>
      </section>
      <section anchor="timestamps">
        <name>Timestamps</name>
        <t>To avoid using fractional numbers and having to deal with rounding errors,
timestamps will be expressed with two integers:
- timestamp numerator (ex: PTS, DTS, duration)
- timebase</t>
        <t>To convert a timestamp into seconds you just need to:
timestamp(s) = timestamp numerator / timebase</t>
        <t>Example:</t>
        <t>PTS = 11, timebase = 30</t>
        <t>PTS(s) = 11/30 = 0.366666</t>
      </section>
      <section anchor="object-format">
        <name>Object Format</name>
        <figure anchor="media-object">
          <name>MOQT Media object</name>
          <artwork><![CDATA[
{
  Media Type (i)
  Media payload (..)
}
]]></artwork>
        </figure>
        <section anchor="media-type">
          <name>Media Type</name>
          <t>This value indicates what kind of media payload will follow</t>
          <table>
            <thead>
              <tr>
                <th align="right">Code</th>
                <th align="left">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="right">0x0</td>
                <td align="left">Video H264 in AVCC with LOC packager</td>
              </tr>
              <tr>
                <td align="right">0x1</td>
                <td align="left">Audio Opus bitsream</td>
              </tr>
              <tr>
                <td align="right">0x2</td>
                <td align="left">UTF-8 text</td>
              </tr>
              <tr>
                <td align="right">0x3</td>
                <td align="left">Audio AAC-LC in MPEG4</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="media-payload">
          <name>Media payload</name>
          <t>Is where media related information is carried, and it is specifed by Media type</t>
          <section anchor="video-h264-in-avcc-with-loc-packager-format">
            <name>Video H264 in AVCC with LOC packager format</name>
            <figure anchor="media-object-video-h264-avcc-loc">
              <name>MOQT Media video h264 loc</name>
              <artwork><![CDATA[
{
  Seq ID (i)
  PTS Timestamp (i)
  DTS Timestamp (i)
  Timebase (i)
  Duration (i)
  Wallclock (i)
  Metadata Size (i)
  Metadata (..)
  Payload (..)
}
]]></artwork>
            </figure>
            <section anchor="seq-id">
              <name>Seq ID</name>
              <t>Monotonically increasing counter for this media track</t>
            </section>
            <section anchor="pts-timestamp">
              <name>PTS Timestamp</name>
              <t>Indicates PTS in timebase</t>
              <t>TODO: Varint does NOT accept easily negative, so it could be challenging to
encode at start (priming)</t>
            </section>
            <section anchor="dts-timestamp">
              <name>DTS Timestamp</name>
              <t>Not needed if B frames are NOT used, in that case should be same value as PTS.</t>
              <t>TODO: Varint does NOT accept easily negative, so it could be challenging to
encode at start (priming)</t>
            </section>
            <section anchor="timebase">
              <name>Timebase</name>
              <t>Units used in PTS, DTS, and duration.</t>
            </section>
            <section anchor="duration">
              <name>Duration</name>
              <t>Duration in timebase.
It will be 0 if not set</t>
            </section>
            <section anchor="wall-clock">
              <name>Wall Clock</name>
              <t>EPOCH time in ms when this frame started being captured.
It will be 0 if not set</t>
            </section>
            <section anchor="metadata-size">
              <name>Metadata Size</name>
              <t>Size in bytes of the metadata section
It can be 0 if no metadata is sent</t>
            </section>
            <section anchor="metadata">
              <name>Metadata</name>
              <t>Extradata needed to decode this stream
This will be  <tt>AVCDecoderConfigurationRecord</tt> as described in
[ISO14496-15:2019] section 5.3.3.1, with field <tt>lengthSizeMinusOne</tt> = 3
(So length = 4). If any other size length is indicated
(in <tt>AVCDecoderConfigurationRecord</tt>) we should error with “Protocol violation”</t>
              <t>Any change in encoding parameters <bcp14>MUST</bcp14> send a new
<tt>AVCDecoderConfigurationRecord</tt></t>
            </section>
            <section anchor="payload">
              <name>Payload</name>
              <t>H264 with bitstream AVC1 format as described in [ISO14496-15:2019] section 5.3.
Using 4bytes size field length.</t>
            </section>
          </section>
          <section anchor="audio-opus-bitsream">
            <name>Audio Opus bitsream</name>
            <figure anchor="media-object-audio-opus-loc">
              <name>MOQT Media audio Opus LOC</name>
              <artwork><![CDATA[
{
  Seq ID (i)
  PTS Timestamp (i)
  Timebase (i)
  Sample Freq (i)
  Num Channels (i)
  Duration (i)
  Wall Clock (i)
  Payload (..)
}
]]></artwork>
            </figure>
            <section anchor="seq-id-1">
              <name>Seq Id</name>
              <t>Monotonically increasing counter for this media track</t>
            </section>
            <section anchor="pts-timestamp-1">
              <name>PTS Timestamp</name>
              <t>Indicates PTS in timebase</t>
              <t>TODO: Varint does NOT accept easily negative, so it could be challenging to
encode at start (priming)</t>
            </section>
            <section anchor="timebase-1">
              <name>Timebase</name>
              <t>Units used in PTS, DTS, and duration</t>
            </section>
            <section anchor="sample-freq">
              <name>Sample Freq</name>
              <t>Sample frequency used in the original signal (before encoding)</t>
            </section>
            <section anchor="num-channels">
              <name>Num Channels</name>
              <t>Number of channels in the original signal (before encoding)</t>
            </section>
            <section anchor="duration-1">
              <name>Duration</name>
              <t>Duration in timebase.
It will be 0 if not set</t>
            </section>
            <section anchor="wallclock">
              <name>Wallclock</name>
              <t>EPOCH time in ms when this frame started being captured.
It will be 0 if not set</t>
            </section>
            <section anchor="payload-1">
              <name>Payload</name>
              <t>Opus packets, as described in <xref target="RFC6716"/> - section 3</t>
            </section>
          </section>
          <section anchor="utf-8-text">
            <name>UTF-8 Text</name>
            <figure anchor="object-utf8-text">
              <name>MOQT UTF-8 Text</name>
              <artwork><![CDATA[
{
  Seq ID (i)
  Payload (..)
}
]]></artwork>
            </figure>
            <section anchor="seq-id-2">
              <name>Seq Id</name>
              <t>Monotonically increasing counter for this media track</t>
            </section>
            <section anchor="payload-2">
              <name>Payload</name>
              <t>Text packets in UTF-8, as described in <xref target="RFC3629"/></t>
            </section>
          </section>
          <section anchor="audio-aac-lc-in-mpeg4-bitstream">
            <name>Audio AAC-LC in MPEG4 bitstream</name>
            <figure anchor="media-object-audio-aaclcmpeg4-loc">
              <name>MOQT Media audio AAC-LC MPEG4 LOC</name>
              <artwork><![CDATA[
{
  Seq ID (i)
  PTS Timestamp (i)
  Timebase (i)
  Sample Freq (i)
  Num Channels (i)
  Duration (i)
  Wall Clock (i)
  Payload (..)
}
]]></artwork>
            </figure>
            <section anchor="seq-id-3">
              <name>Seq Id</name>
              <t>Monotonically increasing counter for this media track</t>
            </section>
            <section anchor="pts-timestamp-2">
              <name>PTS Timestamp</name>
              <t>Indicates PTS in timebase</t>
              <t>TODO: Varint does NOT accept easily negative, so it could be challenging to
encode at start (priming)</t>
            </section>
            <section anchor="timebase-2">
              <name>Timebase</name>
              <t>Units used in PTS, DTS, and duration</t>
            </section>
            <section anchor="sample-freq-1">
              <name>Sample Freq</name>
              <t>Sample frequency used in the original signal (before encoding)</t>
            </section>
            <section anchor="num-channels-1">
              <name>Num Channels</name>
              <t>Number of channels in the original signal (before encoding)</t>
            </section>
            <section anchor="duration-2">
              <name>Duration</name>
              <t>Duration in timebase.
It will be 0 if not set</t>
            </section>
            <section anchor="wallclock-1">
              <name>Wallclock</name>
              <t>EPOCH time in ms when this frame started being captured.
It will be 0 if not set</t>
            </section>
            <section anchor="payload-3">
              <name>Payload</name>
              <t>AAC frame (syntax element <tt>raw_data_block()</tt>), as described in section 4.4.2.1 of [ISO14496-3:2009].</t>
            </section>
          </section>
        </section>
      </section>
    </section>
    <section anchor="references">
      <name>References</name>
      <t>[ISO14496-15:2019] "Carriage of network abstraction layer (NAL) unit
structured video in the ISO base media file format", ISO ISO14496-15:2019,
International Organization for Standardization, October, 2022.</t>
      <t>[ISO14496-3:2009] "Information technology — Coding of audio-visual objects",
ISO ISO14496-3:2009, International Organization for Standardization, September, 2009.</t>
    </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="RFC6716">
        <front>
          <title>Definition of the Opus Audio Codec</title>
          <author fullname="JM. Valin" initials="JM." surname="Valin"/>
          <author fullname="K. Vos" initials="K." surname="Vos"/>
          <author fullname="T. Terriberry" initials="T." surname="Terriberry"/>
          <date month="September" year="2012"/>
          <abstract>
            <t>This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6716"/>
        <seriesInfo name="DOI" value="10.17487/RFC6716"/>
      </reference>
      <reference anchor="RFC3629">
        <front>
          <title>UTF-8, a transformation format of ISO 10646</title>
          <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
          <date month="November" year="2003"/>
          <abstract>
            <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="63"/>
        <seriesInfo name="RFC" value="3629"/>
        <seriesInfo name="DOI" value="10.17487/RFC3629"/>
      </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 391?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAEs0b2cAA+1Z21Ijxxm+76foiBspJQkJ8HpX5ZMswKsEEAti166tLdOa
aUljRtPydA9CXnD5IXKZVOVZ8ih+knx/d8+MEGBYx3ElVWarVjN9+I/ff+ie
RqPBTGRi2eGVQ/WKH8owEryfGJmqeYWJ0SiVl5ibqe8bs6jCAmHkRKXLDo+S
sWIsVEEiZtgdpmJsGoFMfhCJatjlRKoROVKNVpvpbDSLtI5UYpZzbOnvDfc5
3+Ai1gosoiSUc4n/ElOp8wp2G5VGIqaXfvdL/KgUTyfD/QpLstlIph0WQpwO
C1SiZaIz3eEmzSSDwNtMpFKA6hs54iIJnUqJNHyYikTPVWoqbKHSi0mqsjkp
bxUfXMqUvzrr9yrsQi4xH3YYb3irqHySXcokA1/OH9zNudOx8gY8omTCv6KV
ND4TUewM+kUkzbip0gkNizSYYnhqzFx3NjdpFQ1Fl7KZL9ukgc1RqhZabmL/
Ju2bRGaajbBTjFNYcHPND6s+oOUxDKbNCiO3renINCP1SwTW59ad3JyaWVxh
TGRmqlKyHDhyPs7i2IHkLzBoxHt+/75MU2nsEmgnkugHYQCODsxthB2Wzljf
eY5fzDDRDNSM3SXdjUXC90kXGcdPoOn0XqGYqHSGtZfwKyNsl2+NRoOLkTap
CAxjw2mk+TxVRgUq5gG4jiTPtAy5URwwDC3cUhlI7OaXUSiVHRFZGCmHoRJO
jNBSQpK/PRy8Gr5rOp6zKAxjydgGgTdVYRaQKusS6LkMonEkNRdcR7N5LPlM
BlOormccaliZCIHWVby6JlGNOZHA164eKTPlMURvQGEpZrSTFr/ucW2WsVUV
Wmupm5wPp7IUJNJsHMuraIRFUQLzh6BLNsnmVjdDYkPTieRqvEKGFJLgHcdq
QdzmIoVHAShdWHdOcR4SVYOlzi5ERNh3cswFr8qrDh/TVpZidR0u0CrOyGR1
HqhQBnUuTVBz7AqpQzmOEms8sLc+mUoRQojgQkygQDVRhh+oHn8bq+Bd3doC
esgrg4xDujKoCJthqcOMhsLBlAvN9w+Pd5rkvuOc2WAuU+GcuLFBbofcR5BY
e6GyURxpIqVlLANDUhG6NaSx+oJNlPJgqpSGpZww5F4sTHj36GhwdtTbY9ig
Ibt1pzV6QQPSvEGgezuW7Eomt8cXURyD7xiPDj3W1I4g8KPZuUXT1+dWknML
KLwssFfyr912+A/CUYYgc2ojUmMxZXgL4pwq8ioBYY01CkUGt2z5uPGMiU3b
B5UdqpcIYFYLLi4pdRIIc/ZOyNZ53UtIT6W87XOPQJQnHaTRKNebqkpEGBbW
CGCktMwFGclYJRNSBO4nETQBr7Qj3A8cG+80O8v1MgmmqcpzkisevGoibDJi
NofscTRJXCbBLmZ30XQMiNaaFjSHYj4ntkMnB1aibA/5YPQdAINnpD/G9q3n
5V1DlfYdSUhvASYXXhJhnKzGCy4FcNzfPWFVDYg7Bq3SqfFCLC3wsIT/VS5t
7NWcae1WRxVmNMKxItAiYGBoO4UEskfrPOkpbGZsJqAwQmA6b9iwf//eLWq4
yZubZqnkCkCeoOQC+Hfi+YRs6dbZY1LzD5SaPSD1cLA76PBdYcQE9qJtC5Ha
/DxPJQJNJkBPoLI4zOtKnY8yxwdJC7ieaR6NnfTM2pyHCrinPDWODFmrkPls
9xgwXMZKhA49wwJrbIgicKmiEDyI+5iqG1ApYu6aKxdsU3HpQR5KTFnrwQqu
oqB+q1TX2QqCc3TIK6ijqSraLWah8hSgO6zBix3EjHIifGkT+PHwtM536b8w
c6my5pePkCMYSQ3XIEsbSv4FFdCm4osp5MKlyvh3mTbwuo2lTilgVdf4p/dy
31xhsnclqI6i9EMcrG+368UsXrdbdsLRarc3t1v4bTW3n9Efs3b24bhv/c7Y
jz/+yN6j+3CFf4jOkFejWjHgXcSrzWaN3bjVHb7heiuPM48v26t/WrHl2rcR
dr5yQ3w3Vjj4PuFSxBnV4zCi1h0OmoIKOtKQInx2i731navDjF037J//eezv
ml3zHnIPv+avLcNH/q49/c5158n0W1ctTvRtTnu59WyHoN593es5iB0MemXV
vv4V8reu2kS/a9PCYJ4hyUdGUw/0sPwfRn+L6J8N9xvPuUED8QT7fBj97VL+
brfXOOiRhQ6P977a+c/pr8LLA4b1tS/1DkepjH2b5rtn1LiImrg0jSiN2dbJ
0JDrWbF0tPQkjUXsBvF4koPHa5F1Kr9HHfJRRVFbZDo/tnvP2DCPab/EZxz/
+gZ1P0DTd1HEqhHoQwU/jX6Q62M2dMH58Uhu2KLcmEK/hrgMggZYPBzdroLT
YvSngY9yGMnpy9ihQt5HSxFA2CXsFQCvNp+jhNChrGwCVxo4llO5ZSjG+kWW
oAnqEsu8a8vWa4FDk3H15mgw5CII5NxwYgnuiZzYI1Odo1+Ao4sqhtNIHMu8
XWIocZQqoK9rNarzNKJzRq2Qa/e2XEfK5XLC1ph/6bp81Ccgj6RwRdI2taBp
e0k9zXnbHsolQWH1av7eygwLI54lSCjurAhpy1JHgZGXu2ZphCw/KxTAXHFJ
k/VNUW1bZBdqADTO0/l+wi/vEYBR0Y4HvZd2L9GY2bhNHC5cC2GFp4CUFjxi
brJUho8zuRUUaOcpNMBhtCQU+eZ3lq9BgbYK9U1+svM0yyWUHGRylz4VZWDX
rvFQsD2JNb7Vwx1XXdHLRebnSB+7dlHaU8k4mnhLnmAsDc8JEqt9JnvbPx20
d3ZePGu0P+pstdov3uVC84+a2/iHTsAmIxy4AYdzAoKZktaHUZLpQSLPqUFg
VZxr3Bxed2pN3kfHliz9QVGTlfw0pM2Lc8iqMN0jItf4ooC37b+cPD//9Pfi
lHkZqdhu+fmnfzDWBVu6DphYx1i4rp2yD89Oh/7mghpl9ogEZfbwZYDZXG3F
oIpp/UB5u52ntTUr80eszM5sBttxILLGcuZ2Jssj5L5K/QEFYS35n9qWj++n
2OdGjrIZ78FwiYz1wxXCRVjO5wnp3zbuDQWpfznzi1I7VL61zB/+6sz/v534
PyxXFiYpfYcU5F7GeMnAcFnQoFSk0gjC4CCjcdDGT3UkYSZZhEUpyar3UYHs
kYgSWpAj4oMp/hb5PPgvp/MipC3uqNuSRtfvBPD793862e89+7j97OaGN4rg
3faB6VrcIVrch+Lx/jjxEZKZ8fOGbZDvCY6S9m8dErnqRDtXnZS1HB+ywfaz
rRc3N7cz0nrvXSTF/5vsJEQQB7O5nOw8JUd5fZ2yf+SqP3LV75yrgD9PqqqX
iRFXXMZyhi6Sn6di8S31jN+OSJhq7bx2N5Dz7LXT3GluNdtkuLJB2UZ/0nrx
zvYc/CS/oIOV7+lhKj066Qr3fSORhj4vFh+OiEMslvRF4ah7UOMZMMMwlQVW
XX/Q844CbW6j34XDOIrzC8ZK3U6uM68z931T+Cu8wcq3LxtcpwZgpItGN1bn
g8AowKTOt1pbW81VfbzKvNJfOccbGUwTFavJEq3m3+iuh5yl/D0kzrQ6A1uX
RHQF4qwK6SjW+YfKeIq4lTMvZeuF/ZbSo9u/hObdBeUufb+J7Lu7xr+QS04f
bjWvUGNLX49tg4tUQM8ne6/O+id7u/R8+rJ7cFA8ML/i9OXg7GC3fCp39gaH
h3tHu24zpZZbQ6xy2P2m4qK+Mjge9gdwdMW5FGAPVZBZUNKxFWeXkbQ3ouk8
lcZ9TLmFyi97x//6Z3vHl5mtdhtlxr88b3+8gxeKI8dNJUhs7hXoWTIxn0uR
2ptg+o4h5pERsSvjODksEk6XNrDmn9+SZd51+CejYN7e+cwPkMK3BnOb3Rq0
Nrs7cmezM+I9Q/ewKax5a3zN0rfl7X5z6z23+8rgJ5/T5xPeaD///DNm4/hU
BlkamSWByX7iETl+UECKWbu03z3q3l12y590M48jrF3pAp2+adovuCNXxng3
uEjUIpbhhHZolF13xy7DTytjuEZSybTMRbESDvo3tT4+R50hAAA=

-->

</rfc>
