<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.4) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rswg-rfc7990-updates-12" number="9720" category="info" submissionType="editorial" obsoletes="7990" updates="9280" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="RFC Formats and Versions">RFC Formats and Versions</title>
    <seriesInfo name="RFC" value="9720"/>
    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization>ICANN</organization>
      <address>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>
    <author initials="H." surname="Flanagan" fullname="Heather Flanagan">
      <organization>Spherical Cow Consulting</organization>
      <address>
        <email>hlf@sphericalcowconsulting.com</email>
      </address>
    </author>
    <date year="2024" month="August" day="06"/>

    <keyword>Internet-Draft</keyword> year="2025" month="January"/>

    <abstract>

<?line 40?>

<t>In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document.
This document describes how RFCs are published.</t>
      <t>This document obsoletes RFC 7990.
This document also updates the stability policy in RFC 9280.</t>
    </abstract>
  </front>
  <middle>

<?line 49?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>

      <t>"RFC Series Format Requirements and Future Development" <xref target="RFC6949"/> discussed the need to improve the display of items such as author names and artwork in RFCs as well as the need to improve the ability of RFCs to be displayed properly on various devices.
Based on the discussions with communities of interest, such as the IETF, the RFC Series Editor decided to explore a change to the format of the Series.
<xref target="RFC7990"/> was the culmination of that exploration.</t>
      <t>This document is concerned with the production of RFCs, focusing on the published documents.
It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Drafts will be are developed).
While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds should be discussed within each document stream.</t>
      <t>The details described in this document are expected to continue to change over time as the community and the RFC Production Center (RPC) gains gain further experience implementing the policies described here.</t>
      <t>Implementors of those these components are advised to avoid assuming that all such changes will be backwards-compatible.</t> backwards compatible.</t>
      <section anchor="changes-to-rfc-7990"><name>Changes anchor="changes-to-rfc-7990">
        <name>Changes to RFC 7990</name>
	<t><xref target="RFC7990"/> defined a framework for how RFCs would be published after that document was published,
 including new formats "publication formats" and a new "canonical format" for archiving RFCs. format".
It talked about "the XML file" as if there would only be one XML file for an RFC because that was the expectation at the time <xref target="RFC7990"/> was published.
It also talked about "publication formats" as the versions of HTML, plain text, and PDF derived from the "canonical format".</t>
        <t>After extensive experience with publishing RFCs in the RFCXML format <xref target="RFC7991"/>, it has been decided that an RFC's XML file can be updated for narrowly limited purposes.
This document changes <xref target="RFC7990"/> in significant ways:</t>

<t><list style="symbols">

<ul spacing="normal">
          <li>
            <t>It defines four terms that replace the use of the term "canonical" and clarifies "format":
  <list style="symbols">
            </t>
            <ul spacing="normal">
              <li>
                <t>The "definitive format", which is RFCXML</t>
              </li>
              <li>
                <t>The "definitive version", which is a published RFC in the definitive format</t>
              </li>
              <li>
                <t>A "publication format", which is currently one of PDF, HTML, plain text, or HTML</t> and PDF</t>
              </li>
              <li>
                <t>A "publication version", which is a published RFC in one of the publication formats</t>
    </list></t>
              </li>
            </ul>
          </li>
          <li>
            <t>It defines a policy governing how the RFCXML format changes.</t>
          </li>
          <li>
            <t>It defines a policy for when the definitive version of an RFC can be updated and older definitive versions archived.</t>
          </li>
          <li>
            <t>It defines a policy for when the publication versions of an RFC can be updated and older publication versions archived.</t>
</list></t>
          </li>
        </ul>
        <t>When using the new terminology, it is important to note that <xref target="RFC7990"/> used the term "canonical format" to mean two very different things. Quoting from RFC 7990:</t>

<ul empty="true"><li>

<blockquote>
            <t>Canonical format: the authorized, recognized, accepted, and archived version of the document</t>
</li></ul>
        </blockquote>
        <t>and</t>

<ul empty="true"><li>
        <blockquote>
            <t>At the highest level, the changes being made to the RFC format involve breaking away from solely ASCII plain text and moving to a canonical format that includes all the information required for rendering a document into a wide variety of publication formats.</t>
</li></ul>
        </blockquote>
        <t>This document uses two terms, "definitive version" and "definitive format", for the earlier term "canonical format".</t>

<t>Other terminology changes made by this
        <t>This document are also makes the following:
- It following terminology changes:</t>

<ul spacing="normal">
	<li>It changes the phrase "xml2rfc version 3" to "RFCXML".
- It "RFCXML".</li>
	<li>It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC Production Center" (RPC).</t> (RPC).</li>
</ul>
        <t>Historical text from <xref target="RFC7990"/> target="RFC7990"/>, such as Section 2 <xref target="RFC7990" section="2" sectionFormat="bare"/> ("Problem Statement"), Section 4 <xref target="RFC7990" section="4" sectionFormat="bare"/> ("Overview of the Decision-Making Process"), and Section 10 <xref target="RFC7990" section="10" sectionFormat="bare"/> ("Transition Plan") were Plan"), was purposely omitted from this document.
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particularly Section 8 (Figures <xref target="RFC7990" section="8" sectionFormat="bare"/> ("Figures and Artwork) Artwork") and Section 9 (Content <xref target="RFC7990" section="9" sectionFormat="bare"/> ("Content and Page Layout) were Layout"), was also removed.</t>
      </section>
      <section anchor="changes-to-9280"><name>Changes anchor="changes-to-9280">
        <name>Changes to RFC 9280</name>

<t>Section 7.6 of <xref target="RFC9280"/> currently
        <t><xref target="RFC9280" sectionFormat="of" section="7.6" /> says:</t>

<ul empty="true"><li>
<blockquote>
            <t>Once published, RFC Series documents are not changed.</t>
</li></ul>
        </blockquote>
        <t>This document replaces that sentence with:</t>

<ul empty="true"><li>
<blockquote>
            <t>Once published, RFCs may be re-issued, reissued, but the semantic content of publication versions shall be preserved to the greatest extent possible.</t>
</li></ul>
</blockquote>
        <t>This document also creates adds a new policy that would exist in Section 7 of to <xref target="RFC9280"/>:</t>

<ul empty="true"><li> target="RFC9280" sectionFormat="of" section="7"/>:</t>

<blockquote>
            <t>7.8.  Consistency</t>

  <t>RFCs
            <t indent="3">RFCs are copyedited, formatted, published, and then published. They may be
    reissued to maintain a consistent presentation.</t>
</li></ul>

<t><xref target="updating"/>
</blockquote>

<t>Sections <xref target="updating" format="counter"/> and <xref target="pub-versions"/> target="pub-versions" format="counter"/> in this document are based on this updated policy in <xref target="RFC9280"/>.</t>
      </section>
      <section anchor="key-changes-from-the-earlier-rfc-process"><name>Key anchor="key-changes-from-the-earlier-rfc-process">
        <name>Key Changes from the Earlier RFC Process</name>

	<t>The first RFC to be published following the guidance of the group of RFCs described in <xref target="RFC7990"/> was <xref target="RFC8651"/>, published in October 2019.
In the time since then, all published RFCs have followed the general plan from <xref target="RFC7990"/>.</t>
        <t>At the highest level, the changes that <xref target="RFC7990"/> made to the RFC format involved breaking away from solely ASCII <xref target="RFC20"/> target="RFC0020"/> plain text and moving to a definitive format that includes all the information required for rendering a document into a wide variety of publication formats.
The RPC became responsible for more than just the plain-text file and a PDF rendering that was created from the plain text at the time of publication; the RPC now creates the definitive version and three publication versions of the RFC in order to meet the diverse requirements of the community.</t>

<t>The final RFCXML file produced by the RPC is the definitive version for RFCs; it holds all the information intended for an RFC.
Additional publication versions (HTML, PDF, and plain text) text, and PDF) are also published by the RPC.
The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t>
      </section>
    </section>
    <section anchor="definitive-version-of-an-rfc"><name>Definitive anchor="definitive-version-of-an-rfc">
      <name>Definitive Version of an RFC</name>

      <t>The definitive version produced by the RPC is the publication version that holds all the information
      intended for an RFC.  The RPC may change the definitive version of an
      RFC over time (that is, change the XML file), as described in <xref
      target="updating"/>.  See <xref target="RFC7991"/> for the original
      complete description of RFCXML.</t>

<t>The XML may contain SVG line art, as originally described in <xref target="RFC7996"/>.
That SVG will also appear in the HTML publication versions. version.
The XML may contain non-ASCII characters, as originally described in <xref target="RFC7997"/>.
These characters will appear in all the publication versions.</t>
      <t>The definitive version must contain all information necessary to render the specified publication versions; any question about what was intended in the publication will be answered from this file.
It is self-contained with all the semantic content known at publication time.
For instance, all features that reference externally defined input are expanded.
It does not contain src attributes for &lt;artwork&gt; or &lt;sourcecode&gt; elements.
It  does not contain comments or processing instructions.</t>
      <section anchor="updating"><name>Updating anchor="updating">
        <name>Updating the Definitive Version of an RFC</name>
        <t>RFCs may be re-issued, reissued, as described in <xref target="changes-to-9280"/>.
Such changes must preserve the semantics expressed in the original RFC.
Reasons to make such changes include updates to the RFCXML schema, errors discovered in the XML, and changes to the tooling used to generate the publication versions of the definitive version of the RFC.
The RPC will keep a public record of when it re-issues reissues any RFC, RFC and give a short description of its reasoning for each change.</t>
      </section>
      <section anchor="expected-updates-to-rfcxml"><name>Expected anchor="expected-updates-to-rfcxml">
        <name>Expected Updates to RFCXML</name>
        <t>It is anticipated that <xref target="RFC7991"/> will be updated.
Updates to the RFCXML specification that are applied to existing RFCs should preserve to the greatest extent possible the semantics expressed in the original RFC. RFC to the greatest extent possible.
The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.</t>

        <t>This policy does not require that updates to RFCXML avoid all risk
        of introducing semantic changes to existing RFCs.  Instead, it only requires that such updates consider
        considering the potential for semantic changes, take taking steps to
        understand the risk of a semantic change (either deliberate or
        inadvertent), and to limit those risks.</t> limiting associated risks are the only
        requirements.
	</t>
      </section>
    </section>
    <section anchor="pub-versions"><name>Publication anchor="pub-versions">
      <name>Publication Versions</name>
      <t>The RPC is permitted but not required to re-issue reissue publication versions of an RFC, as described in <xref target="changes-to-9280"/>.
In deciding whether to update the publication versions of an RFC, the RPC will take into account both the risk of semantic changes and consistency of the series.</t> Series.</t>
      <t>XML format errors and better design choices have been discovered by the community since the first RFCs were published using the RFCXML format.
When the XML in a definitive version changes, the publication versions may change, even if this might not result in observable differences.
Similarly, as production tools change, publication versions may be regenerated to ensure a consistent presentation.</t>
    </section>
    <section anchor="archived-documents"><name>Archived anchor="archived-documents">
      <name>Archived Documents</name>
      <t>The RPC will keep an archived set of all definitive versions of RFCs as well as archived sets of the publication versions for an RFC that were previously published.
These archived sets must be available using the same access methods as for current definitive and publication versions.
Every archived set shall record the date that a definitive and/or publication version was created or reissued.</t>
      <t>When the RPC archives definitive and publication versions, it does so in a manner that allows them to be found by people who want the historical (as compared to current) files.</t>
      <t>This document does not specify how archives are maintained or how archived documents might be located or identified.
The methods for storage and access will be determined by the RPC in consultation with the technical community.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations.</t> actions.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>

      <t>Allowing changes to the definitive versions version and publication versions
      of RFCs introduces risks.  A significant risk is that unintended changes
      could occur in either the definitive version or publication versions of
      an RFC as a result of an editing error, or error. In addition, unintended changes
      may be introduced into a publication version when it is regenerated from
      the definitive version.  This may result in the corruption of a
      standard, practice, or critical piece of information about a protocol, and
      which may harm to the reputation of the RFC series.</t> Series.
      </t>
      <t>The RPC is expected to identify, track, and actively mitigate risks introduced by this new policy.</t>
    </section>
  </middle>
  <back>
<displayreference target="RFC0020" to="RFC20"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7991.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7996.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7997.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9280.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7990.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8651.xml"/>
      </references>
    </references>

    <section anchor="acknowledgments"><name>Acknowledgments</name>

<t>Martin Thomson anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t><contact fullname="Martin Thomson"/> wrote a great deal of the significant text here as part of draft-thomson-rswg-syntax-change.</t> draft-thomson-rswg-syntax-change-01.</t>
      <t>This document has greatly benefited from the input of the RSWG.
In particular,
Alexis Rossi,
Brian Carpenter,
Eliot Lear,
Jay Daley,
Jean Mahoney,
John Levine,
and Pete Resnick,
gave
<contact fullname="Alexis Rossi"/>,
<contact fullname="Brian Carpenter"/>,
<contact fullname="Eliot Lear"/>,
<contact fullname="Jay Daley"/>,
<contact fullname="Jean Mahoney"/>,
<contact fullname="John Levine"/>,
and <contact fullname="Pete Resnick"/>
provided significant input on the early drafts draft versions of this document.</t>
    </section>

  </middle>

  <back>

<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">

<reference anchor="RFC7991">
  <front>
    <title>The "xml2rfc" Version 3 Vocabulary</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <date month="December" year="2016"/>
    <abstract>
      <t>This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7991"/>
  <seriesInfo name="DOI" value="10.17487/RFC7991"/>
</reference>
<reference anchor="RFC7996">
  <front>
    <title>SVG Drawings for RFCs: SVG 1.2 RFC</title>
    <author fullname="N. Brownlee" initials="N." surname="Brownlee"/>
    <date month="December" year="2016"/>
    <abstract>
      <t>This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7996"/>
  <seriesInfo name="DOI" value="10.17487/RFC7996"/>
</reference>
<reference anchor="RFC7997">
  <front>
    <title>The Use of Non-ASCII Characters in RFCs</title>
    <author fullname="H. Flanagan" initials="H." role="editor" surname="Flanagan"/>
    <date month="December" year="2016"/>
    <abstract>
      <t>In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.</t>
      <t>This document updates RFC 7322. Please view this document in PDF form to see the full text.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7997"/>
  <seriesInfo name="DOI" value="10.17487/RFC7997"/>
</reference>
<reference anchor="RFC9280">
  <front>
    <title>RFC Editor Model (Version 3)</title>
    <author fullname="P. Saint-Andre" initials="P." role="editor" surname="Saint-Andre"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.</t>
      <t>This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9280"/>
  <seriesInfo name="DOI" value="10.17487/RFC9280"/>
</reference>

    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="RFC20">
  <front>
    <title>ASCII format for network interchange</title>
    <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
    <date month="October" year="1969"/>
  </front>
  <seriesInfo name="STD" value="80"/>
  <seriesInfo name="RFC" value="20"/>
  <seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference>
<reference anchor="RFC6949">
  <front>
    <title>RFC Series Format Requirements and Future Development</title>
    <author fullname="H. Flanagan" initials="H." surname="Flanagan"/>
    <author fullname="N. Brownlee" initials="N." surname="Brownlee"/>
    <date month="May" year="2013"/>
    <abstract>
      <t>This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6949"/>
  <seriesInfo name="DOI" value="10.17487/RFC6949"/>
</reference>
<reference anchor="RFC7990">
  <front>
    <title>RFC Format Framework</title>
    <author fullname="H. Flanagan" initials="H." surname="Flanagan"/>
    <date month="December" year="2016"/>
    <abstract>
      <t>In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7990"/>
  <seriesInfo name="DOI" value="10.17487/RFC7990"/>
</reference>
<reference anchor="RFC8651">
  <front>
    <title>Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension</title>
    <author fullname="B. Cheng" initials="B." surname="Cheng"/>
    <author fullname="D. Wiggins" initials="D." surname="Wiggins"/>
    <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
    <date month="October" year="2019"/>
    <abstract>
      <t>This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8651"/>
  <seriesInfo name="DOI" value="10.17487/RFC8651"/>
</reference>

    </references>

</references>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA71aa4/byLH9zl/RkIGbMSDp2pPEXo+BRSZjO55kvevr8W7y
7aJFtqTOUGymmxxZMfzf76mq7ib1sp0vF1hjOVQ/qutx6lQ1Z7NZ0dmuNlfq
w5sb9cb5je6C0k2lfjM+WNeEQi8W3jx8ZUDlykZvsETl9bKb+bBdzfyyfP7i
xZNZ31a6M2H29LIoQodp/6tr12Bs53tTYNXfF24RXG0w6ErRlCJOuVIvLn94
UhS29Tw6dJdPnrx4clncb6/UbdMZ35hu9oq2LErdXSnbLF0R+sXGBpLr467F
NqaynfNW10Wh+27t/FWhZoVSGI0d3s/VW7dcbnRDr+QQ73Vfj986v8J+N9c/
/0x/mY229ZVqMWi+lkF/sqVumjnGjZd+O1dvat3o1Xjtt0Z3a+P3fuH171q8
xjq1unFb/GtCX3e2WY22XNfLP4U0rHTbMg+al25TFA2bxj4YnJBsBV0+HR6f
DY/P4yOp9wr6hdr2Z14+iQ/PXvzhxTAvvf3h2R+xcDGbzZRehM7rsiuK2wYH
qXC0zim7ab17MApHVd7oSi9sbbudckuaHtR2bWujQt+2zpP8NNB6pX25tg9x
8JRnV2ZpG0uiqQfxNlqEfiFnvIMuTIBv6CZgENyqUkvvNqqttW1mnfnUqeu7
m9tbEuof735SfYi70XR68eBKvehr7XcvVWWXS+NN06m2X9RQMq2YtoXHezpM
gyOmXbq17tRCB4jpyn6DmfPi49qG/CfED6W3C8i4hlX57LQMrx/WppoXBxNy
KPD5SOeHS+o6OBUjhE+CoIrqbR2k3sH7eDJZF+uzmTa2qmpTFI8obryr+pLO
VhSTkRYlstUH86/eekN7SZS/6bseMr8yD6Z2Lb2fqM+fo3N8+QK1hbIPAUoh
aRpDD/sugBEwCJvfdmYTYPlyrTSW54Dk0JC9tO+2zt/HIwQaszV1Tf8/t/ih
b+HnRd4SwzGyNb7GANhSe+t6KNM82NKEefFnTXLjlygmHYSNvbXdWiGqNj15
H6Qj2QlyTOimWX6adfv645vpoUe+ZtDBPqWtRGTzqa0d1KhVudbNytA7miSh
l5xaps8L1i9ZH/rdxo3Kvt7YRpySh2OarMrvjlwJz0CIklCykvPQKm22ftLY
FDKUEhhREdk982IQ6Rbe7HC0xsEHqwqKIJPt4nFCOg/Wh2YDXhgNJQEdjN4g
7mREJU7EtkZKsWYbQ39A7aAuQgu9LQnlasAARc4+2pN54BRkZlnPVI/nxd8Z
VG5nrxBs+oE0HezGIrRVMKxgrN9HP4uKwdkr+HrZwT3imQQfHGI6DoeBZNGw
dn1dReeKHk9qha/yUbPi5cxsD5KwA3iHjAQV+Xa3H9FwCxgSYoirQDiAYs8u
Ep0Fzg5gtRuTvC655o6Pk7zv/WDcG0MqUxcf3t88ViugIU7Se849tBfcDBqg
QKo51BMsMoSQBw/yYorBYW7TUOeD+B8pCXK0gF3GCvLu6sEGOYV+cBYBDSVu
ZHFN2FVL7CSnSXZc6PJ+q30VZrQg/HlR056PHqmbwb0SIhZ74cEZAltqYDJw
hOGDbJYBd5vMNrg1fIj0SSJlK1CY5RFTWKms+4okb+CkyxHr0fxmgpTvGk7Y
8uOEd5UURtNob46aTtf3tOfC9Z2akJIp8SzhrBOypuXIh+5ETtfAFyEslJrH
ycqC6gtTakSTCJ+gQbxHoAGv6RU7yyGMjPLObcwk+9KNE1888yS5XE6EMP7b
j+9+Aughv05ZJ+9fvYEhPNJ0To3mhIpg0mtWPSYapOwHM3ZGxqgoYtKgREtO
1xEt07mefvkCS3WI9wDFmGYAXPY21tjvwqBHCES6lexZsVob7b3bQuc1wIJe
tr1v4dnhMO8mlx3rFMIFu2oYq9iFdoF4kSKsZLck+OjhacZvggjlDfJSKamL
7BiBn0aMFDYRlAJ4YW2sMokKJAKm1EwRskxG3Cj+PCVmhfCyISrszPBoyvF4
PQoP8rOo96M94orXp3xlvF7Ze6JSnHf5lHCRqfCy6DdQPrnR6QW/T8K4dM5Z
+567bwid6NGKwLQhByOIOHauaOj5menkNNu1OVLPiJ7GUD3wNrKoq4khH88K
ETgoMr9j25P89Ds2PsNr085Iodhg4MiEc+SYtnG1W+041GAIJA3QdnJ4gDLo
QASjcWD0iQ4e+HXGSszcGIgJukeS7EbkmzLqKszV//SO0xLjScJ+hNeP6uZg
uSshgkwm7b8JvZHTHeKSn3VZmrbjJ2aYctrDciLFOarEpqJNrgVH13a1BudT
NTEN4XkJCRaGxNvoKpM5kjJ6kW0eXA0Do3LW9zROAx3kLMTwERdSmAwRweJt
HCcPyp/qUGuiZklM5BpInbRpLt9wGC/kXaBNihXee8QKG157C5hkOmyEOp8I
nyNCKSQOBmM4m55EFD7ESWQiiThXaV9b4895Bnb9hVnKyPGyxlnXi90J/iRU
uq7dFue9khjKzJQiZu2pTpt82tSXfllm6/+eXXEiCDCZH0+k2iT5yMJVOzFC
QqIgSYrNyrWUEP+86DEjmwglwzHf2kCNCTo7m58XGQdRqjLujCxwqS4mWA/U
aKPukO2ZjU0eT/OAP2DALzgZ8+oo8ytkRDrp7J244Xvh5zSNTJWmPn2CuR9z
Ha3e17qZPEbxxdUqZ0SCcqTIbkjxIyMgW548Q8p5hpFom0gLYTdbWQqQFnWf
LakMxyZJpB/UxRu7QukptOtaSsPHe2K/UBc3YMvsBURDNLjyT3oHLhNlZ46D
atYJwJ1glFQmq8+Pos1nnZvRmy9FkfZ4Pn9GyuRT8U9fRsktSMr/Uf1CDGbE
H0fFYC6i2FOpfpLNjqv/SA4iVQjkMIkYnduEgoIJozczrljwetELdgWzAUrb
kisK7i4sT6eAsNbCw1toG/4jDJ6WWHmyXOiEscHxHUokIecn2hKljI4UOWYu
YapMbs0n+DwZP+v2QLN8yufzH+aKW2AYDQXs8A7/5e5J6doddfXoqIIa/DjS
CyNpUotohTMOoLYjuNWkEVm9kzM3XSqiP3/mvIlYgaFpoc+fsfIs6UpY3zEA
LYZOAn5KqXfoyIwOKYXN38wuu2KmzK8jOEbooEiVMnJpPTRHr6W/MVChjHpi
r95Wmrwkhv/Ku77NvZG9IvSwOOC/qbVHpHpYHyN/KTu3gFSXT56+mFOjLxcY
oArCZZsp56M9hhbrcBEw8oGVaYwH4sHPmyO0oPLgm1n3iGt8PQFX38zAvNYl
rfSVXHyU0f7fkzF5ATIHF4Ab8uvQkg8vYnm4cZwFodV/9kGUOGqCcvUjxSuV
aoMwuYyU0B1Vb2NljErKffFeitYhVgMuncL/DDOWToU35/lrMqEd9ZI3xnSx
PUdDTVKrIGqclNsh8xQuDZws8Xo6vPS9yB12WWZ7VlTSKHnwS64uQZ5PW5g6
gk0VLSzke15cVxXnUF2fPueFFM9cD5FKBkU/lh4KIekQSIO84gMnnIOnHcT2
AWbRRsu+powlzTUZNyRhTo5gC1kVvx3WM6mfdaSsr6j2hALE5f5DnSbnJ1BP
/dNvlV9Dz+xCYhVEYzQ3eQYRoSNkHFLAHDzAjBsOmciCu63YzahlRT37uEg7
aq5ik+iRtB1L7yQF3f32F1WjxKOWN0uQloOJTsL0M5LlIx2EpnLjjD1FtyBX
PtXr5Fsn3W5+UgqQ75mgIDRD9zgY/V3SPBdpTDCjmVGqLFAy72l5zrnThvAr
CUhLjL2jMZQTNQrGzkUYE6qTvfrUZi+5U/2vHimFgYibXSMyGj3OHlfXqUEJ
YrwdX/zAv8l5uI+GZ7Dj5SzKnLrt6fRHLOweWMl9uvFG5Kjz4o0jxdE1aWkk
oy4BqcyBI5PmIrk0zMd8MpB0QG3T9rmbrOlE+137pNPgS+zewaZ9Fxvc/1V3
L+Pdy48q/h1c70vU0ZX5URlp/UpD83hFgl+BY58uACi50Em8VD9BSM+vMa5i
aXIebMDIcwwWxRmeexy3hyyewnfcb2bfSiR3zzqBlEYXAIMf5ABnCPpgdCD4
Zh55b/b72JEHDPdymY5QxIVyjV2mynhPzXO6PiBwGnb6ByUE7vjtX6Z0DvwR
2upjT13YU2e+2gT65rXpAKfs3ffGtKm5VnLnxFc0mrtNtssKl+sezBdRV1bu
WNbOd4fIZ+EKnvXFDRx4Bd+QyOnEE16nC49fB5XFnmWMKTaLbZmV7JE+AuEU
l5Foz4tfT2s+3SR1OfNwim3b2qZ7OZQBudsc73gGD/l6FfSfeRBpfeXwFzTE
3WbaNlmc+/7YLuwQUp84f7rTnsqNM5oKHHCHsLV3a5eKtFiF5LCNDEr00R/q
P93cQMHehvt488k5nnYd4Gzw1T0lUoWAykpX3C/kc8UNU11LkZO25UIsoXjr
SL1WukFHO6EO4MDrTMu79oT+/EkJT07C6sOJ6sJY5jmVqQEVHECMs7pCcNCO
sRmCNdku8W6LFoy86P0o1tJXL4CoPZJV5LAilVP3inslVIyPlF5J4pKQ+kYj
9zsR7jbee5ABELTSPUvfCHxHv3iaWRtHFStZKpOydD3cfeHi5XFS8ZEPxDvV
VLAnsAnxOrsYtdcjCNKMhek6NgtdomAtR5fyUjTKbc4AlJFaDteeufIcSuOQ
2lUpDo6+9hAR5tLnTiSQ+wEnAHPwunMaHNgosP2B0HIp1GCD8jVZnT7RYaq9
oFDWhBqp182fINzJJTXddNMN3dAvJPAPef2zAnBKTIlBIK0JvXxpcLbJ8Uhd
pz74q9SdKk6lhWZomMdbdMKFUxcYqccw+mRjPDWnppMHGV1wSkXKhqQvBFwf
ACCji0shnftLc1onlvagoUtS8WD6QNUy3QEEjENwuIplpB1jG298HC7ITtLV
13xNsacNaZvFjMlpV6fLEH2w6H+7k7cve6U3dwmE26S7mBSYcdvwPaIy7DLW
ozpg50awNum+W1MzhouzTWwlLRHjHGCtcahjACEOYjWpEZOb1BckKt3ORxCL
2nvMRPj4tiBnG8nBO75ty+egLJzacXL00c+j705iKEHM2pVJS8gXQB9i+5JU
k1k5aUBc6gJzs0OsPnwsIncKB5Vqo+KHdInxR7DrTLmWq4lxd4E+obr++Vra
k5WRb2/C4eHpQrpxMrLcGylL3Bloj2DscJnr1Mw7YIInrwzPOEAOxZS2sUzM
Zdd799UM5zZmZRww1UFp71K+SCghK6kpZtFz/PLM9eJA6QkREiDKW+riMpOh
nMA3whHRsuRV6pGdDJ7IUG3Yg8DcwjqWMl7q0y4DMkti8b7P/FUrphXaU1uZ
iltL5RghBozGLtFaI03WcXEqdaUmEO9c6WphFSiPN8mM3qBEG33CJe2unCZH
BGL8QVD0d/okEsLcx4vMkg4GbCQiuSLgYRuPVZduyoZm/FwpBv+SatDaVKuI
/O/oAqZRH9duE0ixnm51tfBeqFE4K6PpyH24N8ifrlDiwgo0SL4A7mQh+RJY
KO0ss//jUOF9+LuXBibbs6EUtUlZd3//C/Od4cJoipAh+qk+ECefFn/2Fo51
o33L123T4nVtAUI/GRr6V9j9la7NDo90+/xOr13Df7l1gzEPAIdpwTdJ1M/5
YAIA4H5arIiSjI8epWryjeZODh6z3N7FGH+ASR84Ff8Hbje5NGwtAAA=

-->
</rfc>