<?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-vasters-json-structure-import-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title>JSON Structure: Import</title>
    <seriesInfo name="Internet-Draft" value="draft-vasters-json-structure-import-01"/>
    <author fullname="Clemens Vasters">
      <organization>Microsoft Corporation</organization>
      <address>
        <email>clemensv@microsoft.com</email>
      </address>
    </author>
    <date year="2025" month="December" day="04"/>
    <area>Web and Internet Transport</area>
    <workgroup>Building Blocks for HTTP APIs</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 43?>

<t>This document specifies the <tt>$import</tt> and <tt>$importdefs</tt> keywords as extensions
to JSON Structure Core. These keywords allow a schema to import definitions from
external schema documents.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://json-structure.github.io/import/draft-vasters-json-structure-import.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-vasters-json-structure-import/"/>.
      </t>
      <t>
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/json-structure/import"/>.</t>
    </note>
  </front>
  <middle>
    <?line 50?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document specifies the <tt>$import</tt> and <tt>$importdefs</tt> keywords, as extensions
to JSON Structure Core <xref target="JSTRUCT-CORE"/>. These keywords allow a schema to import
definitions from external schema documents.</t>
      <t>All type reference expressions in JSON Structure Core, <tt>$ref</tt> and <tt>$extends</tt> and
<tt>$addins</tt>, are limited to references within the current schema document.</t>
      <t>The <tt>$import</tt> and <tt>$importdefs</tt> keywords enable schema authors to incorporate
external schema documents into a schema.</t>
      <t>Imports do not establish a reference relationship between the importing schema
and the imported schema. Imports <em>copy</em> definitions from the imported schema
into the importing schema and those definitions are then treated as if they were
defined locally.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
<?line -6?>
      </t>
    </section>
    <section anchor="import-and-importdefs-keywords">
      <name>The <tt>$import</tt> and <tt>$importdefs</tt> Keywords</name>
      <t>The <tt>$import</tt> and <tt>$importdefs</tt> keywords are used to import definitions from
external schema documents into a local namespace within the current schema
document.</t>
      <t>A schema processor MUST process the <tt>$import</tt> and <tt>$importdefs</tt> keywords before
processing any other keywords in the schema document.</t>
      <t>The result of importing definitions is that the imported definitions are merged
into the local <tt>definitions</tt> section under the designated namespace as if they were
defined locally.</t>
      <t>A schema that uses <tt>$import</tt> or <tt>$importdefs</tt> MAY <em>shadow</em> any imported
definitions with local definitions of the same name and in the same namespace,
replacing the imported definition entirely. Local definitions take precedence
over the imported definitions. A shadowing type cannot reference the imported
type that it shadows.</t>
      <t>When importing definitions into a local namespace, the processor MUST ensure
that all imported cross-references are resolved within the imported definitions
themselves and not to the local schema. That means that any <tt>jsonpointer</tt>
instance (<tt>$ref</tt> or <tt>$extends</tt> or <tt>$addins</tt>) within imported definitions MUST be
prefixed with the local namespace under which the definitions were imported.
This applies recursively to any imported schema that itself contains imports.</t>
      <section anchor="import-keyword">
        <name><tt>$import</tt> Keyword</name>
        <t>The <tt>$import</tt> keyword is a reference expression whose value is an absolute URI
pointing to an external schema document. It is used to import all type
definitions of the external schema into a local namespace within the current
schema document.</t>
        <t>When the keyword is used at the root level of a schema, the imported definitions
are available in the schema's root namespace. When used within the <tt>definitions</tt>
section, the imported definitions are available in the respective local
namespace.</t>
        <ul empty="true">
          <li>
            <t><strong>Reminder</strong>: Any type declaration at the root level of a schema and any type
declaration at the root level of the <tt>definitions</tt> section is placed in the schema's
root namespace per section 3.3 of <xref target="JSTRUCT-CORE"/>.</t>
          </li>
        </ul>
        <t>Example for <tt>$import</tt> at the root level:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "$import": "https://example.com/people.json"
}
]]></sourcecode>
        <t>Importing into the root namespace within the <tt>definitions</tt> section is equivalent to
the prior example:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "definitions": {
    "$import": "https://example.com/people.json"
  }
}
]]></sourcecode>
        <t>One can also import into any local namespace within the <tt>definitions</tt> section:</t>
        <sourcecode type="json"><![CDATA[
{
  "definitions": {
    "People": {
      "$import": "https://example.com/people.json"
    }
  }
}
]]></sourcecode>
        <t>The result of the import is that <em>all</em> definitions from the external schema are
available under the <tt>People</tt> namespace. The namespace structure and any
cross-references that exist within an imported schema, including any imports
that it may have, are unaffected by being imported.</t>
        <t>The <tt>$import</tt> keyword MAY be used many times within a schema to import multiple
external schemas into distinct local namespaces.</t>
      </section>
      <section anchor="importdefs-keyword">
        <name><tt>$importdefs</tt> Keyword</name>
        <t>The <tt>$importdefs</tt> keyword is a reference expression whose value is an absolute
URI pointing to an external schema document.</t>
        <t><tt>$importdefs</tt> works the same as <tt>$import</tt>, with the exception that it only
imports the <tt>definitions</tt> section of the external schema and not the root type.</t>
        <t>The purpose of <tt>$importdefs</tt> is to use the type definitions from an external
schema as a library of types that can be referenced from within the local schema
without importing the root type of the external schema.</t>
      </section>
    </section>
    <section anchor="examples">
      <name>Examples</name>
      <section anchor="example-import-external-schema">
        <name>Example: Using <tt>$import</tt> to import an external schema</name>
        <t>Let the external schema be defined as follows:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "$id": "https://example.com/people.json",
  "name": "Person",
  "type": "object",
  "properties": {
    "firstName": { "type": "string" },
    "lastName": { "type": "string" },
    "address": { "$ref": "#/definitions/Address" }
  },
  "definitions": {
    "Address": {
      "type": "object",
      "properties": {
        "street": { "type": "string" },
        "city": { "type": "string" }
      }
    }
  }
}
]]></sourcecode>
        <t>The importing schema uses <tt>$import</tt> to import the external schema into the
"People" namespace. The imported <tt>Person</tt> type is then used in the local schema
as the type of the <tt>person</tt> property:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "type": "object",
  "properties": {
    "person": {
      "type": { "$ref": "#/definitions/People/Person" }
    },
    "shippingAddress": {
      "type": { "$ref": "#/definitions/People/Address" }
    }
  },
  "definitions": {
    "People": {
      "$import": "https://example.com/people.json"
    }
  }
}
]]></sourcecode>
        <t>The imported <tt>Person</tt> type from the root of the external schema is available
under the <tt>People</tt> namespace in the local schema, alongside the imported
<tt>Address</tt> type.</t>
        <t>The external schema can also be imported into the root namespace of the local
schema by using <tt>$import</tt> at the root level of the schema document—in which case
the imported definitions are available in the root namespace of the local
schema:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "$import": "https://example.com/people.json",
  "type": "object",
  "properties": {
    "person": {
      "type": { "$ref": "#/definitions/Person" }
    },
    "shippingAddress": {
      "type": { "$ref": "#/definitions/Address" }
    }
  }
}
]]></sourcecode>
        <t>The following schema is equivalent to the prior example:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "type": "object",
  "properties": {
    "person": {
      "type": { "$ref": "#/definitions/Person" }
    },
    "shippingAddress": {
      "type": { "$ref": "#/definitions/Address" }
    }
  },
  "definitions": {
    "$import": "https://example.com/people.json"
  }
}
]]></sourcecode>
      </section>
      <section anchor="example-import-shadowing">
        <name>Example: Using <tt>$import</tt> with shadowing</name>
        <t>The external schema remains the same as in <xref target="example-import-external-schema"/>.</t>
        <t>The importing schema uses <tt>$import</tt> to import the external schema into the
"People" namespace. The imported <tt>Person</tt> type is then used in the local schema
as the type of the <tt>person</tt> property. The local schema then also defines an
<tt>Address</tt> type that shadows the imported <tt>Address</tt> type within the same
namespace:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "type": "object",
  "properties": {
    "person": {
      "type": { "$ref": "#/definitions/People/Person" }
    }
  },
  "definitions": {
    "People": {
      "$import": "https://example.com/people.json",
      "Address": {
        "type": "object",
        "properties": {
          "street": { "type": "string" },
          "city": { "type": "string" },
          "postalCode": { "type": "string" },
          "country": { "type": "string" }
        }
      }
    }
  }
}
]]></sourcecode>
      </section>
      <section anchor="example-importdefs">
        <name>Example: Using <tt>$importdefs</tt> to import the <tt>definitions</tt> section of an external schema</name>
        <t>The external schema remains the same as in Example 4.1.</t>
        <t>The importing schema uses <tt>$importdefs</tt> to import the <tt>definitions</tt> section of the
external schema into the "People" namespace. The imported <tt>Address</tt> type is then
used in the local schema as the type of the <tt>shippingAddress</tt> property as
before. However, the <tt>Person</tt> type is not imported and available.</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "type": "object",
  "properties": {
    "shippingAddress": {
      "type": { "$ref": "#/definitions/People/Address" }
    }
  },
  "definitions": {
    "People": {
      "$importdefs": "https://example.com/people.json"
    }
  }
}
]]></sourcecode>
      </section>
    </section>
    <section anchor="resolving-uris">
      <name>Resolving URIs</name>
      <t>When resolving URIs, schema processors MUST follow the rules defined in
<xref target="RFC3986"/> and <xref target="RFC3987"/></t>
      <t>This specification does not define any additional rules for resolving URIs into
schema documents.</t>
      <section anchor="enabling-the-extensions">
        <name>Enabling the Extensions</name>
        <t>The import extensions are available and enabled by default via the extended
meta-schema:</t>
        <sourcecode type="json"><![CDATA[
{
  "$schema": "https://json-structure.org/meta/extended/v0/#",
  "$id": "myschema",
  "$import": "https://example.com/people.json",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
    },
    "address": {
      "type": { "$ref": "#/definitions/Person/Address" }
    }
  }
}
]]></sourcecode>
      </section>
    </section>
    <section anchor="security-and-interoperability">
      <name>Security and Interoperability</name>
      <ul spacing="normal">
        <li>
          <t>Schema processing engines MUST resolve the absolute URIs specified in
<tt>$import</tt> and <tt>$importdefs</tt>, fetch the external schemas, and validate them to
be schema documents.</t>
        </li>
        <li>
          <t>Implementations SHOULD employ caching and robust error handling for remote
schema retrieval.</t>
        </li>
        <li>
          <t>External schema URIs SHOULD originate from trusted sources.</t>
        </li>
        <li>
          <t>Remote fetching of schemas SHOULD be performed over secure protocols (e.g.,
HTTPS) to mitigate tampering.</t>
        </li>
        <li>
          <t>Excessively deep or circular import chains MUST be detected and mitigated to
avoid performance degradation and potential denial-of-service conditions.</t>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not require any IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <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="RFC3986">
        <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="RFC3987">
        <front>
          <title>Internationalized Resource Identifiers (IRIs)</title>
          <author fullname="M. Duerst" initials="M." surname="Duerst"/>
          <author fullname="M. Suignard" initials="M." surname="Suignard"/>
          <date month="January" year="2005"/>
          <abstract>
            <t>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.</t>
            <t>The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3987"/>
        <seriesInfo name="DOI" value="10.17487/RFC3987"/>
      </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="JSTRUCT-CORE" target="https://json-structure.github.io/core/draft-vasters-json-structure-core.html">
        <front>
          <title>JSON Structure Core</title>
          <author fullname="Clemens Vasters">
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
    </references>
    <?line 382?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Vaa3IbuRH+j1Mg1FZl16WhLNvZByvZRJa1sTa25UhUtvLL
BGdAEqvhYAJgKDMqbuUQOUDOkqPkJOnGY16coSjHTrL+YXEwjUZ34+sXBlEU
EWKESfmIDr6/unhDr4wqYlMoGDhf5lKZAYmZ4XOp1iOqTUJIIuOMLeF9otjM
RCumDVc6+lHLLNJhdiTs5OjxMdHFdCm0FjIz6xzZno2/o/SAslRLWFVkCc85
/JeZwSEd8EQYqQRL8eH85Dn8kQp+XY6/G5CsWE65GpEEJBrRJ4+f/Co6fhI9
fkZimWme6UKPKEjAyWpEnxKmOBvRH/iUsiyh5xmImXFDx4plGoUjt1LdzJUs
8hF9Xog0EdmcPk9lfKPpDBZ9OR6/pSdvzzW54WugTUYlk+gF6k5WPCv4iFDq
uYyfv4AHp+YPwBwZ/h5fweiSiTRQMBUvwu+5MItiCoZoGvBIeOtTmoK22gDF
wphcj46OmpRDx2EopJ9ztMfGDBdmmQ4IYYVZSLAojWAhSmdFmrrNPU35EixK
/+S42LdSzVkm/soM7OWIvhaxklrODD2VCnjaYUvHna6xY7H63TJQDmO5JCST
agnEK2u5y+9Onxwff+N/Pv3m6y+rn1/5n18ff/UMf35/Nb68Ph1HpxeXZyO7
Ujd0USA+sASlfvZfdI+Chqk5B0vfa+gYFthtZqSwRiZEZLNKY0KiKKJsCpQs
NoSMF0JTcKkChDFU5zwWM8E1NQtOJ5+5zZpYAIenhM/0hHpIaso05e8NaALW
18RI2mGLIR0vuOa1SWkqbymjOl7AZlGY5XhTYC4ygTsJPqBgt5C3ylgaSIOo
euhVWYokSTkhB+gcSiawLMymdwei9rj5zxU93EtTendXR8lms7fqpK063aX6
SZpaP6eKz7jiWcyBPFfcxjlNRdYl3CGoBvRBS6tMou0jmXzGEghAegJ6Ankq
lsLwBMUrV9D0FgAIrNFkcaGUNWRTtiEaek/k8IxNUx44OE/R1iBZ7D2a9+8/
UAFpsCOs69IF7jHNpKEQsoC90AugqYykeGrjhF6InE65ueXc6eMkxIDpGBIU
vHoBpvAL0bDOu1jm63dbiO2aRKysXctQt4wEhNQZ4RYAOYgGOQT5APbEDIfW
9BZUcWCBccgWAKj1EPF/KjNICI7B3UFcPW3cptzgZGv5wevrqzEmOPxL31zY
35dnf7w+vzx7gb+vXp68elX+IJ7i6uXF9asX1a9q5unF69dnb164yTBKG0Nk
8Prkz/AGdR1cvB2fX7w5eTWgFkl1p7RaS9gW3FuuAM5OddBWx0pM4QHmPD99
+89/HD8DT/uFD96bjX/AQA0Pt2A5t5rM0rV/RNsRluecKeQCVqMxy4WBMsC6
tl7I24wuwLhD8uvfpmBdGn35228JWvY+SP8hQBqijqs7gCaqKKKA+c0D3AOt
UWjngw+OjsE7LD4oZhydM8B/rweTmgefBHa5kuD2GmoRCxT/uH9umHLIPJz4
eYh6lq2phPmqIvLidAcSiGhFaqic1TynbgWB0jDTdLq2Jy05pNWkckJnlEmN
bEI1d3mjgEpQWSoAnZhn1vsq+93vh6XxrFywgbpmK7Bk01TgGPSdXrBE3r6z
xglKNNIB7pqXuj4sZ85yIJ0V0W5FMGcYtHIfEsXzlMVovh5TUQwWEB7XQ/pq
ayXDbjhsP495gmGUyJU3UpfNhxRsYFWyy2GWilmGMbmKw/W5xJJYcwnjZ2KO
+wEDYM+2d6LbOnkbtFiWw0ZZ9uj0pcRYE+qolt0QKoA3ma7gbc1RunQEfnyp
OZBqa3XUroGukC3GuO6Ss8wDFfd4grVaLm2QmwAsIVOhTT732dmCpEzO9snn
5i+CWJ1Qt+pO0d1g8L3XoSZShWIH8tuFiBce6jWsgTlK/kNXNkHYTLFWAgAU
SkMdCVEVN6CG1wbqhQHTzCikIMMEbpdLmZilDmre4MNmFTV9TNiKkn4cvZ11
VjygC6bQFUsLbqkyLHFlWhhOry/PiTW2RSNK3VtZQXI3OL0VdpkvtkiH87VZ
7R13yXbAs4A3C17X14riA5ySgLKUg/lx9VD6HPaDFBHNVtAM2UKrEWh/qR27
UsQhtcvb9WrSNqIk8VGyf0nauSTsUo4zVx6KpFqVkG/po0eXfIl9uHr0aERP
AFU2IiQ8Tplr63ZbwHog89OA370TtxQrwz9YHOMkT9rWArZNe9EcXChMezp8
iny3in9Czt6zZQ6WmNVC/2RbKmjMfvrpJ4wL5A5awcFnbt1Bf9cNzfDRkhvm
esHV46MDKLRwpm/cazO5kwG736OcS/yJzAZkg4uGyhndo0yRLV37AFG3G/9L
IcABsaQwkrhILEBrv/rH07AmAMy+s53zg9SmdBNUv8hscrKHQcHdnQsDnHY4
cacV2ip2CvrWSlI+P1h0FL6mQLNIqtyyrIzeQfTq6VLasQt8l1S+W1VCEyfz
pB4scN3KMuWmBVckW9nVCsPfC22CHVnWzh6H2PqlRRIqRZ83SKgNlmxNF2zF
XY9aZGw2A8vD9OkaEp8FcJm4elIIFlxTX1gvbcwQy6qz7TiRWIJpBWjfrrV9
EZKAQiC0aYOllewafUKZ8Oq9QSvpNSrpD0p8BBIf3TfxEdJcGI8mdVVIsloR
e1jVFfx9zHPr/2GHsOEiftt2hIue5FlWUiECYUD3W5kXKkdVYWpTVGHPDGBD
7TSfOVpor6ke8i5Dk6ZiqphaW3lgokcpBoRp7WglcUxq7l+v8QiOy8LUStWG
/D3K2pbdZwdsHL3LY4t4UL4Y0WvbNlU4rlUl29tZcgnH34EgcgTA+xU3naaf
equ5s4aZxFMq/TGzUrJPfLO06ENI/JarcgwNiWNy+iNAyI1BoQ852EBhWkXX
mVDavHEM7qppICCYcUA3h44sZftQQdWNbuaIsDZHooOjGrqOTjyJC8r96emk
YhXCfodKdrxDLTsO0nFudkps6WJh1j1UnmjTnUa2zqZazWsFvd7CF16QkOHa
2aKM9RO3sRPnHTZPhcKzy72Yrhw71G655+Bttf54QN0XaE6Cjv3shYozy5FH
ddgEDzU8j8zB9P04uY9vA4n0Pjx+giqkZ3/LasMGxL6uSVdNA9lVeHQhBKqB
VGZzLZLWucLE22RSzyPtpcvqb1pToa8O9uK7JiZEzjVgtxmke5uOVtr919/+
LjLfh8dMc/LAtupe4f4nbcUn96OP7EBdnlMHtkuGtbjYbnboJ2x2fuZ2/OgN
267ayNal1cnjVjVUvtp0hwKFH46zZtkLrnZ3d09VtRn+7BOoW6E+zTG1kdEV
hthctEKqK5f9iW3zTKhFWKud0bLVAdDPw1O6MvcnTLBlLbjthf2FY3/puH/x
uLt8bNBBM2ZYeiqT3UV04CqLzKh76lK6q0Ltd3zXBjadq7ft3KNrQn4PixDh
kO/Z8HivUPAgiTEk9MUKen+saPqhDxakL1jQrmDRyglV1MBvs+4b35C+lLdQ
6ajDULg1IxR29aVM9owoFDPD/3oA+L+ptREGH1ZvH9BL+6EKAXZ9eY7nByoM
RIUSiF97nK8aZIdbH3b9VyNX4riissDziHAWIGBX7vzFqM3G7lx4/moTbtX4
yzSxO3FPJHf77XjYgzz8foUvAWeOPx6HN2WzmG5/FPGnaGd4UyQcrJyVd3DQ
c/2bCN5E1e2cTd0La7d2WnU0quNuodgjRBCY4UHqSrAyQ0MvkhBEW1SvqOkH
4TXw2z4XWa49l09aa/uDla0TCB+HDxuFIPsQ70Cn31lPH9Ar/IYoMHaES5Eo
KJuKFAfvDrR/765QtN7Dvkb0qoFhhAXP5rZAsVj2n3DtDtY/ApY4dbCmu64w
HNIZN/Giq07T7mYJFP8Cr4EiyRI/eFBsILfhG+F9IXvVz7iLR9TfneEwLNfQ
9sULd9ydQD83LTTAVSnwjgWMWMw7V1lKw2GNMg/BlnGQARc4ayUHq6tfRSoB
pkE5XR+uYAE8bpeFsmfUEQQSZO30xeUg6IcDbs9jar914R1CmGm//Ns9sl/a
jYxlqunnfDgfInDwzurVF5jalgCKuTUQIJcjwJysds/sF+SE8xw/b8dCxUWK
13Kcu8YLm2P952wgM+6QH00UuCbO5GwlRRKksx/REz5XLPHf/mBCDsplRtj7
DBn8ieQs0lytBNDGMkv8lQV7f/DkzQleosKDBMXCPSrBMhbFjdGt24RlyFPY
FyoX8yw7Fgf+9rLilMU3uNRJfJPJWwg7cwsTcjdyV4t58pvBDGpuPsA1Ll5c
AINACZny351gP3wvLQAA

-->

</rfc>
