<?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-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title>JSON Structure: Import</title>
    <seriesInfo name="Internet-Draft" value="draft-vasters-json-structure-import-00"/>
    <author fullname="Clemens Vasters">
      <organization>Microsoft Corporation</organization>
      <address>
        <email>clemensv@microsoft.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="02"/>
    <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:
H4sIAAAAAAAAA9Va63YbtxH+j6dAqZzTxEdL+ZLGCU+bVJblWqltuRLVnP4y
wV2QRLRcbAAsZVaHOX2IPkCfpY/SJ+kMLnvjLkW5dtv4h8XFDgYzg29uWERR
RIgRJuUjOvj+8vwNvTSqiE2hYOBsmUtlBiRmhs+lWo+oNgkhiYwztoT3iWIz
E62YNlzp6Ects0iH2ZGwk6OHD4kupkuhtZCZWefI9nT8gtIDylItYVWRJTzn
8F9mBod0wBNhpBIsxYez42fwRyr4dTF+MSBZsZxyNSIJSDSijx8+/k308Gn0
8DGJZaZ5pgs9oiABJ6sRfUKY4mxEf+BTyrKEnmUgZsYNHSuWaRSO3Eh1PVey
yEf0WSHSRGRz+iyV8bWmM1j05Xj8lh6/PdPkmq+BNhmVTKLnqDtZ8azgI0Kp
5zJ+9hwenJo/AHNk+Ad8BaNLJtJAwVS8CL/nwiyKKRiiacAj4a1PaQraagMU
C2NyPTo6alIOHYehkH7O0R4bM1yYZToghBVmIcGiNIKFKJ0Vaeo29yTlS7Ao
/bPjYt9KNWeZ+CszsJcj+lrESmo5M/REKuBphy0dd7rGjsXq98tAOYzlkpBM
qiUQr6zlLl6cPH706Bv/88k3X39V/Xzqf3796OmX+PP7y/HF1ck4Ojm/OB3Z
lbqhiwLxgSUo9bP/ojsUNEzNOVj6TkPHsMBuMyOFNTIhIptVGhMSRRFlU6Bk
sSFkvBCagksVIIyhOuexmAmuqVlwOvnMbdbEAjg8JXymJ9RDUlOmKX9vQBOw
viZG0g5bDOl4wTWvTUpTeUMZ1fECNovCLMebAnORCdxJ8AEFu4W8VcbSQBpE
1UOvylIkScoJOUDnUDKBZWE2vT0QtcfNf67o4V6a0tvbOko2m71VJ23V6S7V
j9PU+jlVfMYVz2IO5LniNs5pKrIu4Q5BNaAPWlplEm0fyeQzlkAA0hPQE8hT
sRSGJyheuYKmNwBAYI0miwulrCGbsg3R0Hsih2dsmvLAwXmKtgbJYu/RvH//
gQpIgx1hXZcucI9pJg2FkAXshV4ATWUkxVMbJ/RC5HTKzQ3nTh8nIQZMx5Cg
4NULMIVfiIZ13sUyX7/bQmzXJGJl7VqGumUkIKTOCLcAyEE0yCHIB7AnZji0
pjegigMLjEO2AECth4j/E5lBQnAMbg/i6mnjNuUaJ1vLD15fXY4xweFf+ubc
/r44/dPV2cXpc/x9+fL41avyB/EUly/Pr149r35VM0/OX78+ffPcTYZR2hgi
g9fHf4E3qOvg/O347PzN8asBtUiqO6XVWsK24N5yBXB2qoO2OlZiCg8w59nJ
23/+49GX4Gm/8sF7s/EPGKjh4QYs51aTWbr2j2g7wvKcM4VcwGo0ZrkwUAZY
19YLeZPRBRh3SH77XQrWpdFX331L0LJ3QfqPAdIQdVzdATRRRREFzG/u4R5o
jUI7H7x3dAzeYfFBMePonAH+ez2Y1Dz4OLDLlQS311CLWKD4x/1zw5RD5uHE
z0PUs2xNJcxXFZEXpzuQQEQrUkPlrOY5dSsIlIaZptO1PWnJIa0mlRM6o0xq
ZBOqucsbBVSCylIB6MQ8s95X2e9uPyyNZ+WCDdQ1W4Elm6YCx6Dv9IIl8uad
NU5QopEOcNe81PVhOXOWA+msiHYrgjnDoJX7kCiepyxG8/WYimKwgPC4HtJX
WysZds1h+3nMEwyjRK68kbpsPqRgA6uSXQ6zVMwyjMlVHK7PJZbEmksYPxNz
3A8YAHu2vRPd1snboMWyHDbKskenLyXGmlBHteyGUAG8yXQFb2uO0qUj8ONL
zYFUW6ujdg10hWwxxnWXnGUeqLjHE6zVcmmD3ARgCZkKbfK5z84WJGVytk8+
N38RxOqEulV3iu4Gg++9DjWRKhQ7kN8sRLzwUK9hDcxR8h+6sgnCZoq1EgCg
UBrqSIiquAE1vDZQLwyYZkYhBRkmcLtcysQsdVDzBh82q6jpY8JWlPTj6O2s
s+IBXTCFrlhacEuVYYkr08JwenVxRqyxLRpR6t7KCpK7wemtsMt8sUU6nK/N
au+4S7YDngW8WfC6vlYUH+CUBJSlHMyPq4fS57AfpIhotoJmyBZajUD7a+3Y
lSIOqV3erleTthEliY+S/UvSziVhl3KcufJQJNWqhHxLHzy44Evsw9WDByN6
DKiyESHhccpcW7fbAtYDmZ8G/O6cuKVYGf7B4hgnedK2FrBt2ovm4EJh2pPh
E+S7VfwTcvqeLXOwxKwW+ifbUkFj9vPPP2NcILfQCg4+c+sO+rtuaIaPltww
1wuuHh4dQKGFM33jXpvJnQzY/R7lXOJPZDYgG1w0VM7oHmWKbOnaB4i63fhP
hQAHxJLCSOIisQCt/eofT8OaADD71nbO91Kb0k1Q/TyzyckeBgV3dy4McNrh
xJ1WaKvYKehbK0n5fG/RUfiaAs0iqXLLsjJ6B9Grp0tpxy7wXVL5blUJTZzM
k3qwwHUry5SbFlyRbGVXKwx/L7QJdmRZO3scYuuXFkmoFH3eIKE2WLI1XbAV
dz1qkbHZDCwP06drSHwWwGXi6kkhWHBNfWG9tDFDLKvOtuNEYgmmFaB9u9b2
RUgCCoHQpg2WVrJr9Allwqv3Bq2k16ikPyjxEUh8dN/ER0hzYTya1FUhyWpF
7GFVV/D3Mc+t/4cdwoaL+G3bES56kmdZSYUIhAHdb2VeqBxVhalNUYU9M4AN
tdN85mihvaZ6yLsMTZqKqWJqbeWBiR6lGBCmtaOVxDGpuX+9xiM4LgtTK1Ub
8vcoa1t2nx2wcfQujy3iQfliRK9s21ThuFaVbG9nySUcfweCyBEA71fcdJp+
6q3mzhpmEk+p9MfMSsk+8c3Sog8h8VuuyjE0JI7J6Y8AITcGhT7kYAOFaRVd
Z0Jp88YxuK2mgYBgxgHdHDqylO1DBVU3upkjwtociQ6Oaug6OvYkLij3p6fj
ilUI+x0q2fEOtew4SMe52SmxpYuFWfdQeaJNdxrZOptqNa8V9HoLX3hBQoZr
Z4sy1k/cxk6cd9g8FQrPLvdiunLsULvlnoO31frjAXVfoDkJOvazFyrOLEce
1WETPNTwPDIH0/fj5C6+DSTSu/D4CaqQnv0tqw0bEPu6Jl01DWRX4dGFEKgG
UpnNtUha5woTb5NJPY+0ly6rv2lNhb462IvvmpgQOdeA3WaQ7m06Wmn3X3/7
u8h8Hx4zzck926o7hfuftBWf3I8+sgN1eU4d2C4Z1uJiu9mhn7DZ+YXb8aM3
bLtqI1uXViePW9VQ+WrTHQoUfjjOmmUvuNrt7R1V1Wb4i0+gboX6NMfURkZX
GGJz0Qqprlz2J7bNM6EWYa12RstWB0C/DE/pytyfMMGWteC2F/YXjv2l4/7F
4+7ysUEHzZhh6YlMdhfRgassMqPuqEvprgq13/FdG9h0rt62c4+uCfndL0KE
Q74vh4/2CgX3khhDQl+soHfHiqYf+mBB+oIF7QoWrZxQRQ38Nuu+8Q3pS3kD
lY46DIVbM0JhV1/KZM+IQjEz/K8HgP+bWhth8GH19gG9sB+qEGBXF2d4fqDC
QFQogfi1x/mqQXa49WHXfzVyJY4rKgs8jwhnAQJ25dZfjNps7M6F56ebcKvG
X6aJ3Yl7Irnbb8fDHuTh9yt8CThz/PE4vCmbxXT7o4g/RTvFmyLhYOW0vIOD
nuvfRPAmqm7nbOpeWLu106qjUR13C8UeIYLADA9SV4KVGRp6kYQg2qJ6RU0/
CK+B3/a5yHLtuXzSWtsfrGydQPg4fNgoBNmHeAc6/c56+oBe4jdEgbEjXIpE
QdlUpDh4e6D9e3eFovUe9jWilw0MIyx4NrcFisWy/4Rrd7D+EbDEqYM13XWF
4ZDOuIkXXXWadjdLoPgXeA0USZb4wYNiA7kN3wjvC9mrfsZdPKL+7gyHYbmG
ti9euOPuBPq5aaEBrkqBdyxgxGLeucpSGg5rlHkItoyDDLjAaSs5WF39KlIJ
MA3K6fpwBQvgcbsslD2jjiCQIGunLy4HQT8ccHseU/utC+8Qwkz75d/ukf3S
bmQsU00/58P5EIGDd1Yvv8DUtgRQzK2BALkcAeZktXtmvyAnnOf4eTsWKi5S
vJbj3DVe2BzrP2cDmXGH/GiiwDVxJmcrKZIgnf2InvC5Yon/9gcTclAuM8Le
Z8jgTyRnkeZqJYA2llniryzY+4PHb47xEhUeJCgW7lEJlrEoboxu3SYsQ57C
vlC5mGfZsTjwt5cVpyy+xqWO4+tM3kDYmVuYkNuRu1rMk98NZlBz8wGucf78
HBgESsiU/wYuEkrWLy0AAA==

-->

</rfc>
