<?xml version='1.0' encoding='utf-8'?> 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.6.39 (Ruby 3.2.2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpapi-yaml-mediatypes-10" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-httpapi-yaml-mediatypes-10" number="9512" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>

    <title>YAML Media Type</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-yaml-mediatypes-10"/> name="RFC" value="9512"/>

    <author initials="R." surname="Polli" fullname="Roberto Polli">
      <organization>Digital
      <organization abbrev="DTD, Italian Government">Digital Transformation Department, Italian Government</organization>
      <address>
        <postal>
          <country>Italy</country>
        </postal>
        <email>robipolli@gmail.com</email>
      </address>
    </author>
    <author initials="E." surname="Wilde" fullname="Erik Wilde">
      <organization>Axway</organization>
      <address>
        <postal>
          <country>Switzerland</country>
        </postal>
        <email>erik.wilde@dret.net</email>
      </address>
    </author>
    <author initials="E." surname="Aro" fullname="Eemeli Aro">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <country>Finland</country>
        </postal>
        <email>eemeli@gmail.com</email>
      </address>
    </author>
    <date year="2023" month="August" day="30"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTPAPI</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="February"/>
    <area>art</area>
    <workgroup>httpapi</workgroup>

    <abstract>
      <?line 71?>
<t>This document registers the application/yaml <tt>application/yaml</tt> media type and the +yaml
<tt>+yaml</tt> structured syntax suffix
on the IANA Media Types registry,
intended to be used to with IANA. Both identify document
components that are serialized according to the YAML specification.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpapi-yaml-mediatypes/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTPAPI Working Group mailing list (<eref target="mailto:httpapi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/httpapi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/httpapi/"/>.
        Working Group information can be found at <eref target="https://datatracker.ietf.org/wg/httpapi/about/"/>. specification.
</t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-httpapi/mediatypes/labels/yaml"/>.</t>
    </note>
    </abstract>

</front>
  <middle>
    <?line 80?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>YAML <xref target="YAML"/> is a data serialization format that is
      capable of conveying one or multiple documents in a single presentation
      stream (e.g., a file or a network resource).  It is widely used on the
      Internet, including in the API sector (e.g., see <xref target="OAS"/>),
      but a corresponding media type and structured syntax suffix had not
      previously been registered by IANA.</t>
      <t>To increase interoperability when exchanging YAML streams, streams and
      leverage content negotiation mechanisms when exchanging YAML resources,
      this specification registers the <tt>application/yaml</tt> media type
      and the <tt>+yaml</tt> structured syntax suffix <xref target="MEDIATYPE"/>.</t>
      target="RFC6838"/>.</t>
      <t>Moreover, it provides security considerations and interoperability
      considerations related to <xref target="YAML"/>, including its relation
      with <xref target="JSON"/>.</t> target="RFC8259"/>.</t>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The
	<t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
<?line -8?>
        </t>

        <t>The terms  "content", "content negotiation", "resource", negotiation" and "user agent" "resource"
        in this document are to be interpreted as in <xref target="HTTP"/>.</t>
        target="RFC9110"/>.</t>
        <t>The terms "fragment" and "fragment identifier" in this document are
        to be interpreted as in <xref target="URI"/>.</t> target="RFC3986"/>.</t>
        <t>The terms "presentation", "stream", "YAML document",
        "representation graph", "tag", "serialization detail", "node", "alias
        node", "anchor" "anchor", and "anchor name" in this document are to be
        interpreted as in <xref target="YAML"/>.</t>

        <t>Figures containing YAML code always start with the "%YAML 1.2" <tt>%YAML</tt>
        directive to improve readability.</t>
      </section>
      <section anchor="application-yaml-fragment">
        <name>Fragment identification</name> Identification</name>
        <t>A fragment identifies a node in a stream.</t>
        <t>A fragment identifier starting with "*"
is to be interpreted as a YAML alias node (see <xref target="fragment-alias-node"/>).</t>

<t>For single-document YAML streams, a fragment identifier that is
        empty or that starts with "/" is to be interpreted as a JSON Pointer
        <xref target="JSON-POINTER"/> target="RFC6901"/> and is evaluated on the YAML
        representation graph,
walking through traversing alias nodes; in particular, the
        empty fragment identifier references the root node.  This syntax can
        only reference the YAML nodes that are on a path that is made up of
        nodes interoperable with the JSON data model (see <xref
        target="int-yaml-and-json"/>).</t>
        <t>A fragment identifier is not guaranteed to reference an existing node.
Therefore, applications SHOULD <bcp14>SHOULD</bcp14> define how an unresolved alias node
ought to be handled.</t>
        <section anchor="fragment-alias-node">
          <name>Fragment identification Identification via alias nodes</name> Alias Nodes</name>
          <t>This section describes how to use
alias nodes (see Section Sections 3.2.2.2 and 7.1 of <xref target="YAML"/>)
as fragment identifiers to designate nodes.</t>
          <t>A YAML alias node can be represented in a URI fragment identifier
by encoding it into bytes using UTF-8 <xref target="UTF-8"/>, target="RFC3629"/>,
but percent-encoding of those characters is not allowed by the fragment rule
in <xref section="3.5" sectionFormat="of" target="URI"/>.</t> target="RFC3986"/>.</t>
          <t>If multiple nodes would match a fragment identifier,
the first occurrence of such a match is selected.</t>
          <t>Users concerned with interoperability of fragment identifiers:</t>
          <ul spacing="normal">
            <li>SHOULD
            <li><bcp14>SHOULD</bcp14> limit alias nodes to a set of characters
that do not require encoding
to be expressed as URI fragment identifiers:
this identifiers
(this is generally possible since
anchor names are a serialization detail;</li>
            <li>SHOULD NOT detail), and</li>
            <li><bcp14>SHOULD NOT</bcp14> use alias nodes that match multiple nodes.</li>
          </ul>
          <t>In the example resource below, the relative reference (see <xref
          section="4.2" sectionFormat="of" target="URI"/>) target="RFC3986"/>)
          <tt>file.yaml#*foo</tt> identifies the first alias node
          <tt>*foo</tt> pointing to the node with value <tt>scalar</tt> and
          not to the one in the second document; document, whereas the relative reference
          <tt>file.yaml#*document_2</tt> identifies the root node of the
          second document <tt>{one: [a, sequence]}</tt>.</t>
          <figure>
            <name>A YAML stream containing two Stream Containing Two YAML documents.</name> Documents</name>
            <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 one: &foo scalar
 two: &bar
   - some
   - sequence
   - items
 ...
 %YAML 1.2
 ---
 &document_2
 one: &foo [a, sequence]
]]></sourcecode>
          </figure>
        </section>
      </section>
    </section>
    <section anchor="media-type-and-structured-syntax-suffix-registrations">
      <name>Media Type and Structured Syntax Suffix registrations</name>
      <t>This Registrations</name>

      <t> This section describes includes the information required for IANA to register
      the above <tt>application/yaml</tt> media type according to and the <tt>+yaml</tt> structured syntax suffix
      per <xref target="MEDIATYPE"/></t> target="RFC6838"/>.</t>

      <section anchor="application-yaml">
        <name>Media Type application/yaml</name> <tt>application/yaml</tt></name>
        <t>The media type for YAML text is <tt>application/yaml</tt>;
the following information serves as the registration form for this media type.</t>
        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>Subtype name:</dt>
          <dd>
            <t>yaml</t>
          </dd>
          <dt>Required parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd>
        </dl>
        <!-- RFC 6838:
   "N/A", written exactly that way, can be used in any field if desired
   to emphasize the fact that it does not apply or that the question was
   not omitted by accident.  Do not use 'none' or other words that could
   be mistaken for a response.
  -->

<dl>
          <dt>Optional parameters:</dt>
          <dd>
            <t>N/A; unrecognized parameters should be ignored</t> ignored.</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>binary</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>see
            <t>See <xref target="security-considerations"/> of this document</t> document.</t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>see
            <t>See <xref target="interoperability-considerations"/> of this document</t> document.</t>
          </dd>
          <dt>Published specification:</dt>
          <dd>
            <t><xref target="YAML"/>, this document</t>
          </dd>
          <dt>Applications that use this media type:</dt>
          <dd>
            <t>Applications that need a human-friendly, cross language, Unicode
based cross-language, and Unicode-based data serialization language designed around the common native data types of dynamic programming languages.</t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>See <xref target="application-yaml-fragment"/> of this document</t> document.</t>
          </dd>
        </dl>
        <t>Additional information:</t>
        <ul spacing="normal">
          <li>Deprecated

        <dt>Additional information:</dt>
	<dd>
	  <t><br/></t>
	<dl spacing="compact">
          <dt>Deprecated alias names for this type:  application/x-yaml,
          type:</dt><dd>application/x-yaml, text/yaml, and text/x-yaml. These
          names are used, used but are not registered.</li>
          <li>Magic number(s)  N/A</li>
          <li>File extension(s): "yaml" (preferred), registered.</dd>
          <dt>Magic number(s):</dt><dd>N/A</dd>
          <dt>File extension(s):</dt><dd>"yaml" (preferred) and "yml". See <xref target="int-yaml-filename-extension"/> of this document.</li>
          <li>Macintosh document.</dd>
          <dt>Macintosh file type code(s):  N/A</li>
          <li>Windows code(s):</dt><dd>N/A</dd>
          <dt>Windows Clipboard Name: YAML</li>
        </ul>
        <dl> Name:</dt><dd>YAML</dd>
	</dl>
	</dd>

          <dt>Person and email address to contact for further information:</dt>
          <dd>
            <t>See the Authors' Addresses section of this document.</t>
          </dd>
          <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>Restrictions on usage:</dt>
          <dd>
            <t>None.</t>
            <t>None</t>
          </dd>
          <dt>Author:</dt>
          <dd>
            <t>See the Authors' Addresses section of this document.</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
      <section anchor="suffix-yaml">
        <name>The +yaml <tt>+yaml</tt> Structured Syntax Suffix</name>
        <t>The suffix
<tt>+yaml</tt> MAY <bcp14>MAY</bcp14> be used with any media type whose representation follows
that established for <tt>application/yaml</tt>.
The media type structured syntax suffix registration form follows.
	See <xref target="MEDIATYPE"/> target="RFC6838"/> for definitions of each part of the registration form headings.</t> form.</t>

        <dl>
          <dt>Name:</dt>
          <dd>
            <t>YAML Ain't Markup Language (YAML)</t>
          </dd>
          <dt>+suffix:</dt>
          <dd>
            <t>+yaml</t>
            <t><tt>+yaml</tt></t>
          </dd>
          <dt>References:</dt>
          <dd>
            <t><xref target="YAML"/>, this document</t>
          </dd>
          <dt>Encoding considerations:</dt>
          <dd>
            <t>Same as "application/yaml"</t> <tt>application/yaml</tt></t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>Same as <tt>application/yaml</tt></t>
          </dd>
          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>Differently from
            <t>Unlike <tt>application/yaml</tt>,
there is no fragment identification syntax defined
for +yaml. <tt>+yaml</tt>.
</t>
            <t>A specific <tt>xxx/yyy+yaml</tt> media type
needs to define the syntax and semantics for fragment identifiers
because the ones defined for "application/yaml" <tt>application/yaml</tt>
do not apply unless explicitly expressed.</t>
          </dd>
          <dt>Interoperability considerations:</dt>
          <dd>
            <t>Same as "application/yaml"</t>
          </dd>
          <dt>Security considerations:</dt>
          <dd>
            <t>Same as "application/yaml"</t> <tt>application/yaml</tt></t>
          </dd>
          <dt>Contact:</dt>
          <dd>
            <t>httpapi@ietf.org or art@ietf.org</t>
          </dd>
          <dt>Author:</dt>
          <dd>
            <t>See the Authors' Addresses section of this document</t> document.</t>
          </dd>
          <dt>Change controller:</dt>
          <dd>
            <t>IETF</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="interoperability-considerations">
      <name>Interoperability Considerations</name>
      <section anchor="int-yaml-evolving">
        <name>YAML is Is an Evolving Language</name>
        <t>YAML is an evolving language and, language, and over time,
some features have been added and others removed.</t>
        <t>This <xref target="YAML"/>

<t>The <tt>application/yaml</tt> media type registration is independent of the YAML version.
This allows content negotiation of version-independent YAML resources.</t>
        <t>Implementers concerned about features related to a specific YAML version
can specify it in YAML documents using the <tt>%YAML</tt> directive
(see Section 6.8.1 of <xref target="YAML"/>).</t>
      </section>
      <section anchor="int-yaml-streams">
        <name>YAML streams</name> Streams</name>
        <t>A YAML stream can contain zero or more YAML documents.</t>

        <t>When receiving a multi-document stream,
an application that only expects one-document streams,
ought to single-document streams
should signal an error instead of ignoring the extra documents.</t>

<t>Current implementations consider different documents in a stream independent,
similarly to JSON Text Sequences text sequences (see <xref target="RFC7464"/>);
elements such as anchors are not guaranteed to be referenceable
across different documents.</t>
      </section>
      <section anchor="int-yaml-filename-extension">
        <name>Filename extension</name> Extension</name>
        <t>The "yaml" filename extension is the preferred one;
it is the most popular and widely used on the web.
The "yml" filename extension is still used.
The simultaneous usage of two filename extensions in the same context
might cause interoperability issues
(e.g., when both a "config.yaml" and a "config.yml" are present).</t>
      </section>
      <section anchor="int-yaml-and-json">
        <name>YAML and JSON</name>
        <t>When using flow collection styles (see Section 7.4 of <xref target="YAML"/>) target="YAML"/>),
a YAML document could look like JSON <xref target="JSON"/>,
thus target="RFC8259"/>;
thus, similar interoperability considerations apply.</t>
        <t>When using YAML as a more efficient format
to serialize information intended to be consumed as JSON,
information not reflected in the representation graph
and classified as presentation or serialization detail details
(see Section 3.2 of <xref target="YAML"/>) can be discarded.
This includes comments (see Section 3.2.3.3 of <xref target="YAML"/>),
directives, and alias nodes (see Section 7.1 of <xref target="YAML"/>)
that do not have a JSON counterpart.</t>
        <figure anchor="example-json-discards-information">
          <name>JSON replaces alias nodes Replaces Alias Nodes with static values.</name> Static Values</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 # This comment will be lost
 # when serializing in JSON.
 Title:
   type: string
   maxLength: &text_limit 64

 Name:
   type: string
   maxLength: *text_limit  # Replaced by the value 64.
]]></sourcecode>
        </figure>
        <t>Implementers need to ensure that relevant
information will not be lost during the processing.
For example, they might consider acceptable
that
alias nodes are being replaced by static values.</t> values as acceptable.</t>
        <t>In some cases cases, an implementer may want to
define a list of allowed YAML features,
taking into account that the following ones features might have interoperability
issues with <xref target="JSON"/>:</t> target="RFC8259"/>:</t>
        <ul spacing="normal">
          <li>multi-document YAML streams;</li>
          <li>non UTF-8 streams</li>
          <li>non-UTF-8 encoding. Before encoding YAML streams in UTF-16 or UTF-32,
it is important to note that <xref section="8.1" sectionFormat="of" target="JSON"/> target="RFC8259"/> mandates the use of UTF-8
when exchanging JSON texts between systems that are not part of a closed ecosystem, ecosystem
and that Section 5.2 of <xref target="YAML"/> recommends the use of UTF-8;</li> UTF-8.</li>
          <li>mapping keys that are not strings;</li>
          <li>circular strings</li>
          <li>cyclic references represented using anchor anchors (see <xref target="sec-yaml-exhaustion"/>
and <xref target="example-yaml-cyclic"/>);</li> target="example-yaml-cyclic"/>)</li>
          <li>
            <tt>.inf</tt> and <tt>.nan</tt> float values, since JSON does not support them;</li> them</li>
          <li>non-JSON types,
including the ones associated with tags like <tt>!!timestamp</tt>
that were included in the default schema of older YAML versions;</li> versions</li>
          <li>tags in general, and specifically the ones that do not map to JSON types like
          types, e.g., custom and local tags such as <tt>!!python/object</tt>
          and <tt>!mytag</tt> (see Section 2.4 of <xref target="YAML"/>);</li> target="YAML"/>)</li>
        </ul>
        <figure anchor="example-unsupported-keys">
          <name>Example of mapping keys Mapping Keys and values not supported Values Not Supported in JSON in a multi-document Multi&nbhy;Document YAML stream</name> Stream</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 non-json-keys:
   0: a number
   [0, 1]: a sequence
   ? {k: v}
   : a map
 ---
 non-json-keys:
   !date 2020-01-01: a timestamp
 non-json-value: !date 2020-01-01
 ...
]]></sourcecode>
        </figure>
      </section>
      <section anchor="int-fragment">
        <name>Fragment identifiers</name> Identifiers</name>
        <t>To allow fragment identifiers to traverse alias nodes, the YAML
        representation graph needs to be generated before the fragment
        identifier evaluation.  It is important that this evaluation will does not
        cause the issues mentioned in Sections <xref target="int-yaml-and-json"/>
        target="int-yaml-and-json" format="counter"/> and in <xref target="security-considerations">Security considerations</xref>
        target="security-considerations" format="counter"/>, such as infinite loops and
        unexpected code execution.</t>
        <t>Implementers need to consider that the YAML version and supported features (e.g., merge keys)
can affect the generation of the representation graph (see <xref target="example-merge-keys"/>).</t>

<t>In <xref target="application-yaml"/>, target="application-yaml-fragment"/>, this document extends the use of specifications based on
the JSON data model with support for YAML fragment identifiers.
This is to improve the interoperability of already consolidated already-consolidated practices,
such as the one of writing <xref target="OAS">OpenAPI documents</xref> in YAML.</t>
        <t><xref target="ex-fragid"/> provides a non-exhaustive list of examples that could to help
readers understand interoperability issues related to fragment identifiers.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Security requirements for both media type types and media type suffix
registrations suffixes
are discussed in Section 4.6 of <xref target="MEDIATYPE"/>.</t> target="RFC6838" sectionFormat="of" section="4.6"/>.</t>
      <section anchor="sec-yaml-code-execution">
        <name>Arbitrary Code Execution</name>
        <t>Care should be used when using YAML tags, tags because their resolution
        might trigger unexpected code execution.</t>

        <t>Code execution in deserializers should be disabled by default, default
and only be enabled explicitly.
In those cases, the latter case, the implementation should ensure - for (for example, via specific functions - functions)
that the code execution results in strictly bounded time/memory limits.</t>
        <t>Many implementations provide safe deserializers addressing that address these issues.</t>
      </section>
      <section anchor="sec-yaml-exhaustion">
        <name>Resource Exhaustion</name>
        <t>YAML documents are rooted, connected, directed graphs
and can contain reference cycles,
so they can't be treated as simple trees (see Section 3.2.1 of <xref target="YAML"/>).
An implementation that treats them as simple trees
risks going into an infinite loop while traversing the YAML representation graph.
This can happen:</t>
        <ul spacing="normal">
          <li>when trying to serialize it as JSON;</li>
          <li>or when JSON or </li>
          <li>when searching/identifying nodes using specifications based on the JSON data model (e.g., <xref target="JSON-POINTER"/>).</li> target="RFC6901"/>).</li>
        </ul>
        <figure anchor="example-yaml-cyclic">
          <name>A cyclic document</name> Cyclic Document</name>
          <sourcecode type="yaml"><![CDATA[
 %YAML 1.2
 ---
 x: &x
   y: *x
]]></sourcecode>
        </figure>

        <t>Even if a representation graph is not cyclic, treating it as a
        simple tree could lead to improper behaviors
(such behaviors, such as the "billion laughs"
or "Exponential Entity Expansion" problem).</t> triggering an
        Exponential Data Expansion (e.g., a Billion Laughs Attack).
	</t>
        <figure anchor="example-yaml-1e9lol">
          <name>A billion laughs document</name> Billion Laughs Document</name>
          <sourcecode type="yaml"><![CDATA[
 %YAML 1.2
 ---
 x1: &a1 ["a", "a"]
 x2: &a2 [*a1, *a1]
 x3: &a3 [*a2, *a2]
]]></sourcecode>
        </figure>
        <t>This can be addressed using processors limiting that limit the anchor recursion depth
and validating validate the input before processing it;
even in these cases cases, it is important
to carefully test the implementation you are going to use.
The same considerations apply when serializing a YAML representation graph
in a format that does not support reference cycles (see <xref target="int-yaml-and-json"/>).</t>
      </section>
      <section anchor="yaml-streams">
        <name>YAML streams</name> Streams</name>
        <t>Incremental parsing and processing of a YAML stream can produce partial results
and later indicate failure to parse the remainder of the stream;
to prevent partial processing, implementers might prefer validating and processing all the documents in a stream at the same time.</t>
        <t>Repeated parsing and re-encoding of a YAML stream can result
in the addition or removal of document delimiters (e.g., <tt>---</tt> or <tt>...</tt>)
as well as the modification of anchor names and other serialization details,
which details that can break signature validation.</t>
      </section>
      <section anchor="expressing-booleans">
        <name>Expressing booleans</name> Booleans</name>
        <t>Section 10.3.2 of <xref target="YAML"/> specifies that only the scalars matching the
regular expression <tt>true|True|TRUE|false|False|FALSE</tt> are interpreted as booleans.
Older YAML versions were more tolerant (e.g., interpreting <tt>NO</tt> and <tt>N</tt> as <tt>False</tt>, <tt>False</tt> and interpreting
<tt>YES</tt> and <tt>Y</tt> as <tt>True</tt>).
When the older syntax is used, a YAML implementation could then interpret
<tt>{insecure: n}</tt> as <tt>{insecure: "n"}</tt> instead of <tt>{insecure: false}</tt>.
Using the syntax defined in Section 10.3.2 of <xref target="YAML"/> prevents these issues.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This specification defines the following new Internet media type <xref target="MEDIATYPE"/>.</t>
      <t>IANA is asked to update
      <t> IANA has updated the "Media Types" registry at <eref target="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</eref>
      target="https://www.iana.org/assignments/media-types">"Media Types"
      registry</eref> with the registration information provided in the section below.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Media Type</th>
            <th align="left">Registration information section</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">application/yaml</td>
            <td align="left"> <xref
      target="application-yaml"/> of this document</td>
          </tr>
        </tbody>
      </table> for the
      media type <tt>application/yaml</tt>.
      </t>

      <t>IANA is asked to update has updated the "Structured <eref
      target="https://www.iana.org/assignments/media-type-structured-suffix">"Structured
      Syntax Suffixes" registry at <eref target="https://www.iana.org/assignments/media-type-structured-suffix">https://www.iana.org/assignments/media-type-structured-suffix</eref> registry</eref> with the registration information provided in the section below.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Suffix</th>
            <th align="left">Registration information section</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">+yaml</td>
            <td align="left">
      <xref target="suffix-yaml"/> of this document</td>
          </tr>
        </tbody>
      </table> for the structured syntax suffix
      <tt>+yaml</tt>.</t>

    </section>
  </middle>
  <back>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC3629" to="UTF-8"/>
<displayreference target="RFC6838" to="MEDIATYPE"/>
<displayreference target="RFC6901" to="JSON-POINTER"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC8259" to="JSON"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>

        <reference anchor="YAML" target="https://yaml.org/spec/1.2.2/">
          <front>
            <title>YAML Ain't Markup Language Version 1.2</title>
            <author initials="" surname="Oren Ben-Kiki"> initials="O" surname="Ben-Kiki">
              <organization/>
            </author>
            <author initials="" surname="Clark Evans"> initials="C" surname="Evans">
              <organization/>
            </author>
            <author initials="" surname="Ingy dot initials="I" surname="dot Net">
              <organization/>
            </author>
            <author initials="" surname="Tina Müller"> initials="T" surname="Müller">
              <organization/>
            </author>
            <author initials="" surname="Pantelis Antoniou"> initials="P" surname="Antoniou">
              <organization/>
            </author>
            <author initials="" surname="Eemeli Aro"> initials="E" surname="Aro">
              <organization/>
            </author>
            <author initials="" surname="Thomas Smith"> initials="T" surname="Smith">
              <organization/>
            </author>
            <date year="2021" month="October" day="01"/>
          </front>
        </reference>

       <reference anchor="OAS">
          <front>
            <title>OpenAPI Specification 3.0.0</title> Specification</title>
            <author initials="" surname="Darrel Miller"> initials="D" surname="Miller">
              <organization/>
            </author>
            <author initials="" surname="Jeremy Whitlock"> initials="J" surname="Whitlock">
              <organization/>
            </author>
            <author initials="" surname="Marsh Gardiner"> initials="M" surname="Gardiner">
              <organization/>
            </author>
            <author initials="" surname="Mike Ralphson"> initials="M" surname="Ralphson">
              <organization/>
            </author>
            <author initials="" surname="Ron Ratovsky"> initials="R" surname="Ratovsky">
              <organization/>
            </author>
            <author initials="" surname="Uri Sarid"> initials="U" surname="Sarid">
              <organization/>
            </author>
            <date year="2017" month="July" day="26"/>
          </front>
        </reference>
        <reference anchor="JSON-POINTER">
          <front>
            <title>JavaScript Object Notation (JSON) Pointer</title>
            <author fullname="P. Bryan" initials="P." role="editor" surname="Bryan"/>
            <author fullname="K. Zyp" initials="K." surname="Zyp"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6901"/>
          <seriesInfo name="DOI" value="10.17487/RFC6901"/>
        </reference>
        <reference anchor="MEDIATYPE">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <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>
        <reference anchor="JSON">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </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>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="URI">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="UTF-8">
          <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"/>
	  <refcontent>v3.0.0</refcontent>
        </reference>
      </references>
      <references>

        <name>Informative References</name>
        <reference anchor="I-D.ietf-jsonpath-base">
          <front>
            <title>JSONPath: Query expressions for JSON</title>
            <author fullname="Stefan Gössner" initials="S." surname="Gössner">
              <organization>Fachhochschule Dortmund</organization>
            </author>
            <author fullname="Glyn Normington" initials="G." surname="Normington">
         </author>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <date day="25" month="August" year="2023"/>
            <abstract>
              <t>   JSONPath defines a string syntax for selecting and extracting JSON
   (RFC 8259) values from a JSON value.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-jsonpath-base-20"/>
        </reference>
        <reference anchor="RFC7464">
          <front>
            <title>JavaScript Object Notation (JSON) Text Sequences</title>
            <author fullname="N. Williams" initials="N." surname="Williams"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7464"/>
          <seriesInfo name="DOI" value="10.17487/RFC7464"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7464.xml"/>

      </references>
    </references>
    <?line 553?>

<section anchor="ex-fragid">
      <name>Examples related Related to fragment identifier interoperability</name> Fragment Identifier Interoperability</name>
      <section anchor="unreferenceable-nodes">
        <name>Unreferenceable nodes</name>
        <t>In this example, Nodes</name>

        <t> This example shows a couple of YAML nodes that cannot be
        referenced based on the JSON data model since their mapping keys are
        not strings.</t>
        <figure anchor="example-unsupported-paths">
          <name>Example of YAML nodes that are not referenceable based Nodes That Are Not Referenceable Based on JSON data model.</name> Data Model</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 a-map-cannot:
   ? {be: expressed}
   : with a JSON Pointer

 0: no numeric mapping keys in JSON
]]></sourcecode>
        </figure>
      </section>
      <section anchor="referencing-a-missing-node">
        <name>Referencing a missing node</name> Missing Node</name>
        <t>In this example example, the fragment <tt>#/0</tt> does not reference an existing node</t> node.</t>
        <figure anchor="example-missing-node">
          <name>Example of a JSON Pointer that does not reference That Does Not Reference an existing node.</name> Existing Node</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 0: "JSON Pointer `#/0` references a string mapping key."
]]></sourcecode>
        </figure>
      </section>
      <section anchor="representation-graph-with-anchors-and-cyclic-references">
        <name>Representation graph Graph with anchors Anchors and cyclic references</name> Cyclic References</name>
        <t>In this YAML document, the <tt>#/foo/bar/baz</tt> fragment identifier
traverses the representation graph and references the string <tt>you</tt>.
Moreover, the presence of a cyclic reference implies that
there are infinite fragment identifiers <tt>#/foo/bat/../bat/bar</tt>
referencing the <tt>&amp;anchor</tt> node.</t>
        <figure anchor="example-cyclic-graph">
          <name>Example of a cyclic reference Cyclic Reference and alias nodes.</name> Alias Nodes</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.2
 ---
 anchor: &anchor
   baz: you
 foo: &foo
   bar: *anchor
   bat: *foo
]]></sourcecode>
        </figure>

	<t>Many YAML implementations will resolve
<eref target="https://yaml.org/type/merge.html">the merge key "&lt;&lt;:"</eref> defined in YAML 1.1
in the representation graph.
This means that the fragment <tt>#/book/author/given_name</tt> references the string <tt>Federico</tt>
and that the fragment <tt>#/book/&lt;&lt;</tt> will not reference any existing node.</t>
        <figure anchor="example-merge-keys">
          <name>Example of YAML merge keys.</name> Merge Keys</name>
          <sourcecode type="example"><![CDATA[ type="yaml"><![CDATA[
 %YAML 1.1
 ---
 # Many implementations use merge keys.
 the-viceroys: &the-viceroys
   title: The Viceroys
   author:
     given_name: Federico
     family_name: De Roberto
 book:
   <<: *the-viceroys
   title: The Illusion
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to Erik Wilde <contact fullname="Erik Wilde"/> and David Biesack <contact fullname="David Biesack"/> for being the initial contributors of to this specification, specification
and to Darrel Miller and Rich Salz <contact fullname="Darrel Miller"/> and <contact fullname="Rich Salz"/> for their support during the adoption phase.</t>
      <t>In addition to the people above, addition, this document owes a lot to the
      extensive discussion inside and outside the HTTPAPI workgroup. Working Group.  The
      following contributors have helped improve this specification by opening
      pull requests, reporting bugs, asking smart questions, drafting or
      reviewing text, and evaluating open issues:</t>
      <t>Tina issues: <contact fullname="Tina
      (tinita) Müller,
Ben Hutton,
Carsten Bormann,
Manu Sporny
and Jason Desrosiers.</t>
    </section>
    <section numbered="false" removeInRFC="true" anchor="faq">
      <name>FAQ</name>
      <dl>
        <dt>Q: Why this document?</dt>
        <dd>
          <t>After all these years, we still lack a proper media-type for YAML.
This has some security implications too
(eg. wrt on identifying parsers or treat downloads)</t>
        </dd>
        <dt>Q: Why using alias nodes as fragment identifiers?</dt>
        <dd>
          <t>Alias nodes are a native YAML feature that allows
addressing any node in a YAML document.
Since YAML is not limited to string keywords,
not all nodes are addressable using JSON Pointers.
Alias nodes are thus the natural choice for fragment identifiers
<xref target="application-yaml-fragment"/>.</t>
        </dd>
        <dt>Q: Why not use plain names for alias nodes? Why not define plain names?</dt>
        <dd>
          <t>Using plain name fragments could have
limited the ability of future xxx+yaml
media types to define their plain name fragments.
Moreover, alias nodes starts with <tt>*</tt> so we found no reason
to strip it when using them in fragments.
</t>
          <t>Preserving <tt>*</tt> had another positive result:
it allows distinguishing
a fragment identifier expressed as an alias node from
one expressed in other formats.
In this document we included JSON Pointer <xref target="JSON-POINTER"/>
which is expected to start with <tt>/</tt>.
Moreover, since JSON Path <xref target="I-D.ietf-jsonpath-base"/> expressions
start with <tt>$</tt>, this mechanism can be extended to JSON Path too.</t>
        </dd>
        <dt>Q: Why not just use JSON Pointer as the primary fragment identifier?</dt>
        <dd>
          <t>Fragment identifiers in YAML always reference
YAML representation graph nodes.
JSON Pointer can only rely on string keywords so
it is not able to reference a generic node in the
representation graph.
</t>
          <t>Since JSON Pointer is a specification unrelated to YAML,
we decided to isolate the impacts of changes in JSON Pointer
on YAML fragments:
only fragments starting with "/" are "delegated" to an external spec,
and if <xref target="JSON-POINTER"/> changes, it will only affect fragments starting with "/".</t>
          <t>The current behaviour for empty fragments is the same
for both JSON Pointer and alias nodes.
Incidentally, it's the only sensible behaviour independently of <xref target="JSON-POINTER"/>.</t>
        </dd>
        <dt>Q: Why describe the YAML/JSON so closely?</dt>
        <dd>
          <t>In the context of Web APIs, YAML is widely used as a more compact way to serialize
content inteded to be consumed according to the JSON data model.
Typical examples are OpenAPI specifications and Kubernetes manifest files,
that can be serialized in both formats.
The YAML media type registration I-D is a spin-off and a building block
for the OpenAPI specification media type registration.
The YAML/JSON section aims at clarifying what developers should expect when using YAML
instead of JSON, and its content arose from common mistakes and FAQs.
</t>
          <t>Please note that we are not imposing any normative restriction on YAML streams;
this is because YAML is defined outside this document.
Instead, we only provide Interoperability and Security considerations that,
by their nature, are not normative.</t>
        </dd>
        <dt>Q: Do we forbid using non-UTF-8 YAML serialization?</dt>
        <dd>
          <t>No. Since <xref target="JSON"/> recommends UTF-8 in interoperability context
we suggest that using UTF-8 is an interoperable behavior.
This is aligned with Section 5.2 of <xref target="YAML"/> that explicitly
recommends UTF-8.</t>
        </dd>
        <dt>Q: Why media type registration information is outside the IANA Considerations?</dt>
        <dd>
          <t>We decided to follow the style adopted in <xref target="HTTP"/> where
the IANA Considerations in <xref section="18.8" sectionFormat="of" target="HTTP"/>
references the <tt>multipart/byteranges</tt> media type registration form
contained in the specification body <xref section="14.6" sectionFormat="of" target="HTTP"/>.</t>
        </dd>
      </dl>
    </section>
    <section numbered="false" removeInRFC="true" anchor="change-log">
      <name>Change Log</name>
      <section numbered="false" anchor="since-draft-ietf-httpapi-yaml-mediatypes-02">
        <name>Since draft-ietf-httpapi-yaml-mediatypes-02</name>
        <ul spacing="normal">
          <li>clarification on fragment identifiers #50.</li>
        </ul>
      </section>
      <section numbered="false" anchor="since-draft-ietf-httpapi-yaml-mediatypes-01">
        <name>Since draft-ietf-httpapi-yaml-mediatypes-01</name>
        <ul spacing="normal">
          <li>application/yaml fragment identifiers compatible with JSON Pointer #41 (#47).</li>
        </ul>
      </section> Müller"/>, <contact fullname="Ben Hutton"/>, <contact
      fullname="Carsten Bormann"/>, <contact fullname="Manu Sporny"/>, and
      <contact fullname="Jason Desrosiers."/></t>
    </section>

</back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7VcbXfbxrH+jl+xoe5NLIekLNlxHDltqthyo9ZvteT65Pj4
hEtySaICARYLiGIc9bfcH3I/3fvH7jwzu8ACBOWkvc1pZQlY7M7Ozs7LM7M7
GAyiIi4Sc6x+PHnxXL0w01iri83KRHo8zs3VcTTNJqleUoNprmfFIDbFbLAo
ipVexYONXiaDJb4p6BM7OLwXTXRh5lm+OVZxOsuiKF7lx6rIS1sc3bv3zb2j
SOdGH6uT1SqJqW2cpVbpdKreGJ0MLuKlidZZfjnPs3J1rH64uHh98vosujQb
ejo9VmdpYfLUFIOnICaKbEHf/qSTLCUCN8ZGq/hYvS+ySV/RjzidmrToK5vl
RW5mln7bLN0vRR5P6NUkW660+2VJjelVnCZxavqKJr7Uq1Wczj9EVyYtzXGk
VIswpTDxY/WOaKaG6o94TU8XGTgGNtnjg4OpLnSR68mlyYfg3zDL5wfr+YFj
44EeZ2VxQJ8tdZzIZ/T4D74pvdD5ZFH3h2Z4El+Zuj88OBjn2dqaqmP6Mjer
rP5yHheLcjykyR7wQq7nfi0P6mU8SPTYJPYAqxvJF4PY2tIM+AUxGi8iXRaL
LCemDGgYRWyzx+rNUL3OkiTmJyI2b7KxyYsseE7UHqunMfWsE3WR69TOsnzJ
sqCempXOiyUv2xm9j3Wq/phd0aLjGX9uhEt5No5X6PMPczzAnPj1JCvTAvKH
zzcN6k6H6l2cTE1A3WkeXwYPmbST67XehEMZajRco9EfprkphiSAzaHO13Hx
s8kTEsb2gCd5Fg5nliaJq4c83Ivs5zhJdGNAbrZrYs9IQjFSlArbrlgysX+P
uWG4oU/i9ItCvdD5ZblSz3U6L/XcqL+a3ILbh8Mj/oIElD44und0SFt4cO+Q
H1brS/8NZD6vcpOq7006+HN8GYcvnpA8XqrTK1rL8PFZOt/QPirUS8cx9/wi
TrV68b//nSQmD5+/1rS/k9iqk7TI0jgrw5ct3vmuaKtpq86XJKcye53PTVGL
PISVN4hdmckBzXh4hH3x6uS8wa1XK5PSjlbn1CqeOdWk7g/vDe81WHT49eDe
14Ojh7tY9FTnuUnUi7g9tz+Z3Cw36t2Cxssml+ErWh67UH/U+ZQUT+OjF/Gl
UW90slrYLA1fvCHi3ugiu7KXm/D52zxW5zqPSQ7Vn85fvRy8fnX28uL0DX3x
7MnDb2hpI+jlQG7OBk9ZiQz+RkOsdLEYjLWlN9FgMFB6bKG4SNNeLGhZSCWW
2IekVeaxJVVso2JhlK6VObNbsS5h1RhBt6PNl/yCeisnRZmbKanitNDXypaz
WXwd0XTQ6uzk5UlghKwbKN/0iezCkD6n3jI1Nqq08msMFR/PNjVtUOlkD0iX
R5Z2LumQn6mpnkwy8HeOjzAUbw8brvZQ5ryMp9PERNEerE2eTYlgehlF/MF7
/PygiBcaIqGVH0LkRThLTNEF2kz0So8To7IZUZVemQ3GJ9po46tlmRTxigby
hFtaQerVUhv6ZJUbSw+lW+KA0cvojhnOh31qM4sT7kMrUkWwl8Qnm5X5xOwP
ozMeek2MSTbCJs9cZzzBy0lSMjNieQXJt2ZSUJ9uEGuMek+b5MN+PxqXBQ1F
/KNRiLX8Yb3EbL53Laxa6KlKSQPQfK5oQ1uiaWxIi3gJog/GG153Yv8FrWc6
oblao7DeebYyuR7HSVxs1HpBn5nryYK0GCiQBWTO2D7LWWLIUEC/EbMLiEJK
rkgRCw+XBl/GdmnbPcnKeg5SXwVkvSEaUSXwzK5RW+JHXSI/+lJe7eTNx4+f
vTh9enZy8ePr099hfz66/+jmhvjwIssNjB45I+BcdkWLabFAZQ5O0PQsPcnF
feLxtrjVbEOzS0iB8Y4REW4IQeEagE9kyhagDNoDRD06+uobJmpvT73MRCDJ
bj+BPKdCACkHo8hHU3DSrOq9eHt+0evLv+rlK/79zelf3p69OX2K389/OHn+
vPolci3Of3j19vnT+rf6yyevXrw4fflUPqanqvEo6r04+ZHegA29V68vzl69
PHneE8kOdRY5nk53MLNIIMEQbSPi7SSPxwZcVN8/ef0//3X4ABygyR8dHtLk
3R+PDr9+QH9AemS0LE027k9a701EUmF0zts4SbD54eGQR0n2yS6ydaoWJO9D
cIvkW3i11BtqbDNVf9ukOk6jJFubnLqjj6inVaKp0SkpiZiMBvfSh55GY6Ii
zlXlFpBQksSnczuMvv0OTq0aPPru95GsF7GAtoLqub0C1nZsGzz2O6Mnu6xH
OoVUzxwfRb+ay5gZsRGOM6Tqm8PDeyxVNSm9Ge1d9NGTpfR/ehUfm/y3j/f2
zRmGu//No4ft4UINi2mKKsFvrA/8CMKBhjqe53q1wPNCzyF/TRswNQW5bXie
ZlODZnBjrar+SifkNLhJyh/sHf7Gyck2pik9i+ekWywrPRKNSjVOaDySLfJl
SfzIKyp4a7PB7v0ntyBnqKemcU6KH9ICa7qEtjGkDfTUaRLZ+c/ai+EcpI97
gSqUeNCv200UnajtRYTlBCuctWOmD7ub5kI3ZsRaqXeXeGS7OaJl0jWr1R2Y
sI8ffbcDfjXAq5ubffCN+C7GdlAxvGVTOmnyxt0sV8UmytwDptQ6Og9uoxOK
laIhfk70hV7azY0oc+r8Sicla2xnvJ2N2pbDfrTWCQefxYKiz/ki4IF9DJlC
RBVPSnLRWU8J4V1TIys3Iw2VkhHkhnlGhhv9DMX9c9ZrQjEZq76qeU0hjyoc
IeGFW6cVnMqKa0tNS0OxCLlE0jawXOTUVCLKXGIPa0nNEr+a1FqkjPjEHqus
Zbf0xJZdD4p5cgQWYv5qojWcALLq4J2fJb0iH46ifx0CFM4gTc0MSpRUOb4t
UyjG5ArrWnE8wgoUbunJvyBPcso7aPcWuiK/IVgy2lJdIus8cDhpomTEZlmm
hoYjpRyFvTC/zl3r+4h6hkescr4eHoL5oj72I/qgg3UsvNRNPE9JCKVLZnN7
k0EWxqYWTDGiWpHe7ZQw8vWI95lzO7D4xKlNQQSX2Ivq7cWzwSNW3PiFVffD
IzLB4oSSlEzAl6oLmghFYGQYyZdDnALK3aqTCSa7yd4l5KkiJi/J52bjUHPn
K3REJLOJOJtVvrnj5TorkylJbjFZqE6d0GeRncW5LVQ2IS9NBIw6tSV9I1/y
6iU0JkvEWwtaSWdP4JNPRXFseXHUQ9fqIDrzQpnEFPo2BIhYirik4LCj4guw
KuzBacbsyc3fS9L81WrgNQutucZSWtFWO5bRHnNvMTObHAEiOCF9sMqsjbGL
aSknAFQC62bZmLXjJbGVj+vZwLsr4eiE8wHZwsPmwmCxRDuaa73EY++q0ERo
9UXdiWfLRs3vfKdMvAA8oK3hBWBfjRBdDaFk9u7OsmwUBaarXuZgD4y4Gc2e
li8IMPkdLyt0OTWzE006eMQqHkuARggGXQxGW5tiq8r4P47W0EZaQuyOSYR0
+o9+OhqpFrmVEo94s2yNo0YfGT19rxH0/b1E3x9uRsTbf/zjH56xkao8hkhR
kBwp/uZzmriSaUWKAlF6MtYMYAyUzZbG/eZ6lb/iwixJGIfD4Xann9fzCEdo
kAayoo/Hgtv8rncS2uzQByJyVMORs8OeukFYX+MLrBDP6/DsXAzcuYRnDnvQ
VZDTqX/B0gpSyVK/sZytkahRUJJxxi55HTeHkER3LMi+V0hvG2nZ9r9uxMkN
xiHahBOFuWYbvB2+PhYFlkFnCixQT4h27BW2rxOngCkMd3D3rAvqIeFoY2QG
PaPjkOwoOi/HRfhS0OQ3nm3krdCLgpXMsXp5cBJF3342GAC/UmAKo209ek6+
9JrC4YJjedJxyUY0BTm8fW+XGP6AQUrJ4YkNafF4xnaNRkI/xHjyhhbaxj+L
EzOjjpyvAlVpnC0h+jfKu3poR8JoJVzWjHiiVbYENWxxaGl5Gw6Veir6Fkrt
i5Rk+gv0k1EfuQsBuc8JTAw6IqKXxGB9aZi9pDEFdLHEVNo+AwrfXq1cDL7F
qsfslEyyecqYV/0e8SdsGPzROcWHNPvo1BvRJlSArsZxqvMNLVU34oAmokE9
JDFoNqAomZVNEMtAVd8KUdSdtq3gr+n8dTlGPAyIJcRt0KnDO9pfNDJQvAZY
opYg4/vthilcSa0W5VKnFO7Ehtw8yFxO9k8lDmTvq7dpjBiMlg2I6rQLL/SN
na+FbsmHd/gRUlLUJmXFHyn5njM0YMB0QxsongAeojhgucRK+u5gGbfcTWAI
Wxw/Z47vjuG6eH0yncZOAgM9wT7JU/iBE45bnIFk01+pCMmWNdTYNY/YZ+V0
EPwqzyH0gpfUTgQ2dV/BHxRHxgOJwG/VCz0npqTlcmzyO3ZfiQYZqGeATKlf
kyLzQW+OVQ8D9NSdFdtU6mCfovMNPRo6tlTBBiwtxh9UHXQwxg0/gU9rF4LR
sqKDEPCAnpZ3cTrN1lY9SeLVONP5VL3k7BAElUSZ9iviJpICTgcpPZ3CI4Oy
YvtGGgoMnZU5a5HGGsiKMqTLuQn7hTqRz01tvDooP/PoemlJftAPELZXL6GY
JVfK4k8fVw1ekjJDTOByIP/syNETwLCC2eYZsibo6+z04lnE1u+iSh7sNNQf
9wRQDe2fyyt4DPbFyY+VPWCfDBYhsJFrjiJa8bXYQytwPrFBex0D9m8b0WHb
8O4EfruMKA81jETyKleA5AyDceQZuzWYKaPJF3bu3HZfC6OngvrR5mHJon9v
zQfewbt9NP9SKJQvhO94/KYCBtybHUpVqZ1WBZ+dEzFwJHpt3vXw6a/RWOjl
aTxjamDxZ3m27FiKvqT24EBLPLgdxbjo2y2MhPZsgZnhX4ry4b9PKpuiRtfX
1webzebLLdCfc7xkF1zkzEABe9vSP+dIaDvT0BPRh11hFfcyJgUqpojDA+tp
4686OMfZySzwU8o0gbqgQI5axuBSFdPxjD5piD+9VDsdg09/+kRUmDRtlzpw
Uisv6tIHanVSJVn/KRUT8aDbOobFWNTM3jZLnjRTLFBEvH+Q+EvV6VWWXEHI
qx30ca8yFsa9vHEpQ/nEP61NPolEXyHLQ6HM0vQjBExqZnTBaO5CXxnJlJH6
hzlFvgECjVTNkj6bDl1I4lKSgd5pqAQE6aTZV4aLYcAepupKSgAcssdgie3M
m9EHru0g7KeZM4MFQZwIhjdxDa5tqacV5KF0va1CiiK47vJmIxBRK4xzSBFn
2DiAHNUYdtSAvR4OHzXArmG9jg7jDdfNPbqpYC4fUxI9Lq5UP5OUcPKWXOh2
dBlF7xac2JyYmFdaC1xRo8vSIbIooQckPiUDqrRPiXSYWdP+yvZraJFhuYSl
Ks8zeADkAOkpZsrevWcPeSu5blD4hKGpAji/LJZza/02Jk463araaWlhRiAC
JLHxEoVICLwyAWwvEGGeu1DdepzlO4rdvn7w8MHNzf7jyMjAVqAxIOIMEolr
tw3XjgPIAwhxpMXN7iDUZSqcr1Y7e+Eid3hy4i84Z3C2/XUsgW/lJWJ1Hkdx
4V8sM1uoVbYCwM7btCP1vjbjoRtm9ygUUCYJfyZtib0kPzo1WWnF7WLlts46
vrcVioTHvI+vi2gZQ2LEnGxhi1zSZX1RAefExxk8I04EzuL5UFiCKQXP+FFe
FSiEmwotWQwChlc4vdsesnlnpG6IyiRxO9UWm6QNWn89fNAAqpv7TSJmlWTZ
pUpQJcMDv8fPD4BjiWVOPD+ZG2erOWzQJ9NBtoZ3uiGfaBJjVF/gkVWBXBP9
aVWpYCQil7FUkNaPwsYSvswEE/YL2JXjYchwkmhr4Sdwb41GyGR14KpROwkQ
8NMjJNPYTigCEZljW4GqAE4nSkHkdibh/vB+0FE/qrSvlbT4zjREK/UQwtFs
7lxujAvdTI601adQSIQHcUUr7TzaQDSphLYkXrJQe864chcMQVHlBZd9MQbE
MSmCHEbB1VJfPzfpvFgcq8+xi34ShP3hA3IkvDd920d3g4+IhjdmlehJnYgQ
MPjhg2ELyOSp59LYNnjI8YrFUk/kayCZe44nvLkGbhXtIBCvm5ZNTp1GJYVR
Iq8M7pM5NlekbBtiyVzEojhOqmlZmZRVnhF52CNDTqA6KqQAQjl9442JnkzM
qmCtLRnBYFJQIXnAmub8GNhnhwhlD+xAxfVcuGpirVHwkEXO19akBSy7Nz7x
w6LiHQ9SCfpSJACux4RlrIbzauQTHrfTmyyTbeURidr0ZTJYtZsbxj5axj50
M5DgSImzkt3yKZeh+p6TjXVGrOGaxNL+8CG2N367f4SwRgwPcSPLC2EB1sqt
Z53TcJ6P0EcMS1HAKAYL1gDpDhBDHbbrqlgQIcOWBKBYwwW1GwvUvsrrSkUX
SgrAb9JMGWydmWTSsM+pn6k09wR9FaofeEm8Z6fbJIFZrvAaRUWtUWXLMUcn
cc5ZbRWkrcNEpKhyl4O6UwGWzku/XpBZ5H1y48j9+NHvKW4x2UzIRWOfZaBG
Q9ohI242GqY6HcGEEVkir33JeLmktUeNbbnCImGCSycBA2EuMDxey6oEqwr2
SMdnk5h9ZBaxQs+tGLjRZ58hUKCNslyNfDZvzRGu6OzKhNCW0CSMyk5oZA3G
Zgn2Y+hmMwe5c/rIpfBEfVcAapJsarpCZU2rI+nCejZMIj2cEE8pIudqvIy6
kCG8q0dTWG0ocksPsvHfSC6YofTV6LPlhhqOmubiqOEAPP6EKQB3WRdCZlhH
3ztGqQkjgfjz/b2+OvxwzDnIOiH1nfp4eayuIAMK73huOzr8DHsIZdKokab/
oX21JMEHLBTHW80l6dXU+qcucUnzbMg8GCiyFYqSLDFznZ3y3SonMBBlWn3N
U7npLuiBiRC/LSjguchEne6sEaAAAwLVSNhKNnxnwUoNk5B9EcnjrInowkau
PgCCXEEMh6xnbRUoarwum2lYsRpNcap7KXWLwszOkhJXUqne78A5PtzZ25H5
2K9knfQFIDuY0GwlC1qmEuDRyFycZa6pE1d53GmqK0taGapwC8turSSjirGd
R780+ZzLMu0+x9SaAqaJ9OK4XsEl3V6n15lekLhDESEuujlLO1IHNzctUFBi
lKaeb+RorEuPUOjfVfgj3o9TpVUqs0sevQdrw0o2Sc9ul1XoBDVusrBZEk9Z
BleolYi5Btgvo0/S0yfINmKDvvdnBarIk+Th1cn5vscqiDfgGm+keErmtyrh
1awkvO0h8rzT4ngcZgPVwiSrqKRoIudjTrsiuBBT6WZLtFcDdm1gq3rh8tbi
84PPHAy2yrxDcFsA9kaSnK00fNHSusRrXWLxENNsINsSOZ7k45i+z0Ea7YlT
vyeA6ntjjd0yqHYL6aUnGKjOaQqs3wrfYHn6UYCmxjkDVol0Lz4eeRPzOW2w
27bmk8YDzIqW0kd/jdwqTR3eLju0zghLzSyjOyiuSeV9jc0OpYSFa5jg6krN
ShOf8SM4z33Ay1N53qgfq5C0WZm6VM0gqpRGc0ZgAhHGhl9SO6ANWUfIEJmz
g6WhqHcjlUUQnxdIlrQhIyfTyuqZaTHEJaycX2O94pX1fuNLdE4rDyxc6sAv
c/hpDURxzJCRszvFeb005fXqO/SPiGetJfXwIWhXl8zApePNnUm8Qq2+4DAH
NtMVaFqeKJ50VdE14cSTtL1SwnP0xqpj2e4xymN7adU8q2ORtGkqSI45cyiG
1fuGO62pU3qY7wI15JKH5b1Q5BtXXBJgFYWHIuD/kRi5EJmPE6bzA3+cxtdE
erR1h8ZWnaWaYn/apa37LpjnnNKW+3ZN0fY1nKwNRdDXW0U+4ozXRdm1exP6
6lF0ekXTiWdcNtFh0VxtoDTvy0K5UkRGe4Kl8gATgFVvT0j3krRQXBhnuY3u
hDaiRzo5kZR+OV/YHgqDybuTk0jEfHVK/5CapUeaEbsedhApg+Un+EJe5uf6
UL3vaS4e732gZ0d4dqTe39WHfUU/8Ow+nt3HsyM8O9oulGpSuJOXh+abJEt8
wamDidyWrqIqhwMAt2U14eXURVs5rIoVJGpVCH5FrhnMrG8Zp6uy8F5fDSvQ
UjyODK9i6rSHQACtuBcQ3IQUwqzkMIV88C7FuclK1hqy36RM1oGrDifdAgK3
QSO9e/dF7IYLdOJDpFb019Y+n6hkbmco4GZNxCxLxY8LaqchzzgKb+csVnx2
zUj5N33r1L6clNIFVw5MsaNR9RQnpZw1wAjGuYRLDbg/9z6i9P0YnMdpLrgZ
vu+aln4I1FhnZQU7DyWgNQGcl+HItTPp4MwYLxkM1BBVCSvR2CFHctOoDN5m
ibAgcmGydnUsigV2mRF5XFjjHVfSZRBtTMOptBFtyRGajyiSG3Hx9NoQ6dpn
AqZ1YhkENMpffQKvE6olo0R6n9QJ7zci+FKyPPDoK76xN0LycSrpXExznGWk
oZwjx/0d3hs2kF6vur1vya4Is5PrNq1U1rpdCXeOIRWXMUaHoyIvzS8X/OPN
29NfZjqx5pdn8vPk+fnpiLdY65yDJ2wYvdrGHgS2YGi9oGZI93gWV92AotHL
Vw5zeTli/IBHHYlPNfrx9Ny9/VHegsYRbSIG8tlx56FdCj62rnLIyUVLVYi6
LxYmrWmIRrRNOdKjcD69kVGCR720Rw+D9Fv4kvmEQtq3lRVvFhuE/vHWqrkd
Zrc8KDkj23bjL7aOLLpRbAvfTM26OggauvNtz5xHQWbYXkpoUa4YzmBbF5zQ
7VVHdLFNv/Wnrtfr9TDWqZarCSxkmfe1XDMwYMzo95EgXO0ilhCLdl5mBW35
LD/XdxOZvwx+1X+/splvHf0SFt3u/u8X8mZ3EO4JDVv/+6jdqgvuprYrXN8q
mPh3U3u7aO0q8vpXJG1QF2INJGz9N4veb2AJVs+Vsf1L8nXrcv1Ger7cJUKQ
oLDUbqfw/H/Sw4fyx3pyCeV36nGS20GPbazk414NyLARfZs26gok2nEHSoAk
+vAaB99LB9G2j7iRsXZ5sqqvaXRbbBRJnkDAiCbg28xvfCrxqQf09UDGP3Y4
9piMTlXp5QBtqXVsnDmMIiDjaQZonDyRSZMOhy/vhqk7jvn5RHbAzYoJLQYM
dwDTOCPokGlfa+hKaGJxdPgES3t1mmjxaO/g3qh2wHcf9PsEb4k7vcYhTek4
yDJpt0wh64a93TxrHfpsBgq3HEgMmOX44A8DMp86AlxX2+oqagCESOBcE18z
sYGuCO5EM51l2cFY5/T/n0edR/g85O/Pg3RQIc544yypY9iIIjJyieoLDlxp
jfUH5vQWxeyoefc1kppOcTgdatKZm6hmUhwMh/zPGGev8kC4eMKfC7NG7gTo
J3Ydt0Wgzb/weQ398zHCzIh8rEzOK8ljanY3bFbQ33h5i5BszbxVTRHKg7Qd
ML9vHETX4dZayYO4k6rRew5TfGJA9b799rj34c7WVTkwmgfcbLgolsl+6LE6
lhxGt9SrOFAK1w/YIMkebFQKDy4P5Pqcg3lMnu5PiJJGu6TmmZlCVWWjqMor
d/b47bejOvET8nHTPurbvdCHVV1JJ+YJILlOqwwjEDG4iidkajYW5SLBn1wl
IncLAW/4a/A4vDZI1bM/Vn6a8maml3Gyca+eGn+TVoTY6pK/puVTd28Z9CxJ
Sq6pvF2bB1MKNU6d7gEsoU4ml2m2Tsx0LkkCdCjZVTP9XY+jnR6jRjq95BRM
fbcWC/JTTe6U+p52MtlyyTCYGgyKGUfgAt14XBZQX963aIQ1EvtR742LluQK
OcTP5zr52Z03gY31KExQwqKn2UocvIUGGgR9WEEB7uzmymRgEB/Za+ezsjVb
gCQrfGtXhXdV5T7EWUOAJuh/WeB3butujlPVLXcCR9UBWoMFXIKCPBD2XpXR
2gr1xpuIfB0+9rgqebvz+TTb5+vf5AaFcTnnq0i4CsYuUbzhD7HZfsSX+zFu
AizkKjZMC6pApCjAJ1bRYoUQmePRY1puXOV1p8AC6n1/p1c/+p7a/FAWBRbs
ic4tTul9D+c1pQe0t0p1ToSlG+bPn7Tlq99sntkqY/Xs5C9dEuaqn+M0n01+
1wM0AaH7y7F6t9g0F+q76FipkxkMroOXaPduDBHTV2vjqi0TyKJWDtutQ4Yq
04gDSFJktgCUj5Kk6h4eNkzVyTBR/HfMfKjWqIxJVQimM64Goc4FdSYy12mS
6andr8h3BSthlVT36XyZWquaSruTYo3CJ+ejyTkWqJ46NQMFV1/E0XAGeNLn
7Kr6EnYoVIHDePc5xewuZuRiFn/qPiRJRmOPUCYX+kGWh2lPg0s3+fw0JgCd
sMhIu916ZuLWE2zDir/+HKZcoVMfTQs4/l3V0NWVBW2Z6wLm1E8rmqzP2mo+
rFczi4/+1sf5S16W6+trOVxDLWsUpnV4hPRX10DMttqDCuUlvIVkdHdE8gpR
n/GRwhTnkbW7R84t4QqwepA45ZQVDRiMhdavYeFzLmpHr7jTS6cCZq5oy7qD
6cBW2SzFXuKgD6EzytguXKFk950qjUsHUKtQn67HCR98iCR83YxolPElIhae
nLXvz1kHtVG3X7uiUAcXyy0NVSaYmeQvzlGjg1GL80HR12vN5YDdl+lRnFzj
qSywYbf/MXIWprqhzCddpHJCCKlHIUXTFOm/lVbkujFF7cvW4yWS6x1cZ3nu
rAPybp67PahypED6LXU9cieDUk1CguticIg6besOElInNP7mDqiL5k0tUrGC
g51OYQGrVmqH81lrrwYhfGlf03DiuHSFI2BmrMjWSGhPYsf5mFxnD0/FfFus
dTdrpHNTBcxVdM2i2ixSkeox5kGtLVpXGx1IVX2PYmQzB0U9JclhCEGO4x6g
nMnjWpDZlgx7ivjSOHaCeURX9nPLwMIweCETdzzE5TjLXCoNGvcFWX/uAekY
fFjVijTFrxW6yP6UU/GoLASVX/jyGiLTwoNi5KAaOzhrkmykeqQ543ob+OsY
qlz5ARND6o9rU5MNy7q7LMSdjkCP78wYdx8Sz7ydCw9v1AcA3DXBuFugkU/H
rPyhKcy7q/K/ffFkGxFh5m9WKLisy4AgC77MqJV7B2f/XI4ZwUc1G6mMGdKf
OBQihthjU6AjuAIzdgc8QpV54WsLdh0fI43mN06cDrLZzJ0HGZfk2LNf6W8z
dU53N9m7+m8Q4RbNIZs6XlogvZNE586JWjNwYq5MAnetqrwRhd0uAGKlUqdm
+PiF7J2iPummc1Te8ClSd9ze3b4gfCYn1JvAhG+lrEut16aCvpCUDlwqf/te
Xp+crlRCVRCu6gt0fImSF0EfbNdhQ+PENG8knhb7sbx7fDHO1jlGvuCku4iR
p8HyIicTcHMg+4z9amLVXGSnPXXeRD6OfR0Aytmkql2mF6Y2ec+9zIZOF/ti
+bD2Wz6N084zOnyESdSxLedzSfHzPQ31TVFyuLJ5h5iv0Khddz7hKPcrsNLr
rkmXY95VZZbYlyaptcbZedwyPAxkG6FfR+KOWfSuYW4kEnToxyZx8aovVkX4
KHdQ5kZkqLNf1bjg6vDR8BHmKR/LvBowy0juVSK7cIDLuHK2I6Odc8QMvebT
HhdigptRaTbdhFS4GkChgmM8dyz3eTb/9aHe3p6Tp19xH/29ox0gxV2nVapk
fdqNIu59dc/VZPz6MQ93jrmVpesck21NEfvb8Jpmde/Bobqz9+Dr/WH0f+D1
qsa8XwAA

-->

</rfc>