draft-oakley-irc-ctcp-01.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.1.2 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc docName="draft-oakley-irc-ctcp-01" category="info" submissionType="independent" updates="1459, 2812">

  <front>
    <title abbrev="IRC Client-to-Client Protocol">Internet Relay Chat: Client-to-Client Protocol (CTCP)</title>

    <author initials="M." surname="Mikulenas" fullname="Mantas Mikulenas">
      <organization>Independent</organization>
      <address>
        <email>grawity@gmail.com</email>
      </address>
    </author>
    <author initials="D." surname="Oakley" fullname="Daniel Oakley">
      <organization>ircdocs</organization>
      <address>
        <email>daniel@danieloaks.net</email>
      </address>
    </author>

    <date year="2017" month="July" day="18"/>

    
    
    

    <abstract>


<t>This document describes the Client-to-Client Protocol (CTCP), which lets Internet Relay Chat (IRC) clients send each other messages that get displayed or responded to in special ways. CTCP has been widely implemented, with most clients supporting it natively. This document outlines how to implement CTCP and the most common messages used.</t>

<t>It updates RFC 1459 and RFC 2812.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The core Internet Relay Chat (IRC) protocol as described in <xref target="RFC1459"/> and <xref target="RFC2812"/> only has a single command for regular user messages, and does not provide a way for clients to exchange information directly. Client-to-Client Protocol (CTCP) messages let clients exchange messages that get displayed or responded to in special ways. Some examples of how CTCP is used is to request special formatting on messages, query other clients for metadata, and help initiate file transfers with other clients.</t>

<t>This document goes over the subset of CTCP which is commonly implemented, and is compatible with clients implementing CTCP as described by older documents.</t>

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>

</section>
<section anchor="message-syntax" title="Message Syntax">

<t>CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies are sent with NOTICE command. To indicate a CTCP query or reply, the body of the message (the second parameter) begins with the CTCP delimiter. The ABNF <xref target="RFC5234"/> for this message body is as follows:</t>

<figure><artwork type="abnf" align="center" name="syntax"><![CDATA[
  delim    = %x01

  command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
                ; any octet except NUL, delim, CR, LF, and " "

  params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
                ; any octet except NUL, delim, CR, and LF

  body     = delim command [ SPACE params ] [ delim ]
]]></artwork></figure>

<t>Commands are case-insensitive. When creating new CTCP commands, authors SHOULD use only alphanumeric characters for ease of implementation.</t>

<t>The final CTCP delimiter SHOULD be sent on outgoing messages for compatibility reasons, and software MUST accept incoming messages which lack it. This is due to how servers implement message truncation and certain clients implement message splitting.</t>

<t>Queries MAY be sent to channels. When these queries are responded to, the responses are sent to the querying client rather than the channel which the query was originally sent to.</t>

<t>Many servers implement optional filtering so that only the ACTION CTCP message can be sent to channels. When this is done, it can typically be enabled or disabled by channel operators with a channel mode.</t>

<t>Here are two examples of CTCP queries and replies:</t>

<figure><artwork><![CDATA[
  :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
  :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01

  :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
  :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
]]></artwork></figure>

</section>
<section anchor="message-types" title="Message Types">

<t>CTCP messages generally take on one of these types. These message types are defined here to simplify understanding, and aren’t differentiated by the protocol itself.</t>

<section anchor="extended-formatting" title="Extended formatting">

<t>This type of CTCP is used to request special formatting of a user-visible message. That is, to send a user-visible message that should be displayed differently from regular messages - e.g. as an action, a whisper, an announcement.</t>

<t>Extended formatting messages are sent as a PRIVMSG, and are expected to be used in channels as well as between clients. There is no automatic response to this message type, as it is not a query nor reply.</t>

<t>These messages are sent as a PRIVMSG and can have parameters, but generate no reply.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  :dan!u@localhost PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
]]></artwork></figure>

</section>
<section anchor="metadata-query" title="Metadata Query">

<t>This type of CTCP is used to provide relatively static information about the target client, user or connection.</t>

<t>This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively). Due to how bouncers interact with multiple clients, there may sometimes be multiple responses to queries.</t>

<t>Metadata queries MUST NOT require the recipient to implement any side effects (beyond sending the reply itself); if a CTCP message causes side effects by design, it should be categorized as an extended query instead.</t>

<t>Metadata queries do not have any parameters, but expect a reply with parameters as the response data.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
  :bob!b@localhost NOTICE alice :\x01VERSION SaberChat 27.5\x01
]]></artwork></figure>

</section>
<section anchor="extended-query" title="Extended Query">

<t>This type of CTCP is used to provide dynamic information or invoke actions from the client.</t>

<t>This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively).</t>

<t>Queries sent to a channel always generate private replies.</t>

<t>Extended queries and replies may have parameters.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  :alice!a@localhost PRIVMSG bob :\x01PING 1473523796 918320\x01
  :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
]]></artwork></figure>

</section>
</section>
<section anchor="messages" title="Messages">

<t>CTCP messages themselves are not standardised. Clients that receive either unexpected messages or known messages with unexpected values SHOULD ignore them and produce no response to the sending user. Clients MAY receive more than one response per user for a query they send, due to multiple clients being connected behind an IRC bouncer.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to the IRCv3 group for giving feedback on this specification, and to Khaled for advice on client flood protection.</t>

<t>Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who wrote and revised related specifications.</t>

<t>Special thanks to dequis, Peter Powell and James Wheare for help with this and related work.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>CTCP messages are completely untrusted data, and clients MUST NOT assume that they are well-formed or complete.</t>

<t>Older CTCP specifications describe quoting methods which are complex and not widely implemented. Implementations SHOULD NOT implement “low-level quoting” or “CTCP-level quoting” when parsing messages.</t>

<t>Older CTCP specifications describe including more than one CTCP message inside a single PRIVMSG or NOTICE command. Implementations SHOULD NOT implement this form of CTCP parsing as it is not widely-implemented and may result in an implementation that can be more easily flooded off the server they are connected to.</t>

<t>CTCP requests can be abused to flood clients off the server they are connected to. Clients may ignore or delay excessive incoming requests to protect against this.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no actions for IANA.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC1459" target='http://www.rfc-editor.org/info/rfc1459'>
<front>
<title>Internet Relay Chat Protocol</title>
<author initials='J.' surname='Oikarinen' fullname='J. Oikarinen'><organization /></author>
<author initials='D.' surname='Reed' fullname='D. Reed'><organization /></author>
<date year='1993' month='May' />
<abstract><t>The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='1459'/>
<seriesInfo name='DOI' value='10.17487/RFC1459'/>
</reference>



<reference  anchor="RFC2812" target='http://www.rfc-editor.org/info/rfc2812'>
<front>
<title>Internet Relay Chat: Client Protocol</title>
<author initials='C.' surname='Kalt' fullname='C. Kalt'><organization /></author>
<date year='2000' month='April' />
<abstract><t>This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2812'/>
<seriesInfo name='DOI' value='10.17487/RFC2812'/>
</reference>



<reference  anchor="RFC2119" target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC5234" target='http://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>



<reference  anchor="RFC5322" target='http://www.rfc-editor.org/info/rfc5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick' role='editor'><organization /></author>
<date year='2008' month='October' />
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of &quot;electronic mail&quot; messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>




    </references>



<section anchor="message-list" title="Message List">

<t>This section is not exhaustive, and only lists those CTCP messages which are widely implemented across the IRC ecosystem.</t>

<t>The reply and parameter lines below use a simplified syntax that represents variables by surrounding them with angle brackets.</t>

<section anchor="action" title="ACTION">

<figure><artwork><![CDATA[
Type:    Extended Formatting
Params:  ACTION <text>
]]></artwork></figure>

<t>This extended formatting message shows that &lt;text&gt; should be displayed as a third-person action or emote; in clients, it’s generally activated with the command <spanx style="verb">/me</spanx>.</t>

<t>If &lt;text&gt; is empty, clients SHOULD still include a single space after <spanx style="verb">ACTION</spanx> (i.e. an empty params section) to help compatibility. Clients SHOULD correctly parse incoming ACTION messages with or without the params section.</t>

<t>ACTION is universally implemented and very commonly used. Clients MUST implement this CTCP message to effectively use IRC.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
  Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01

  Formatted:  * dan does it!
]]></artwork></figure>

<figure><artwork><![CDATA[
  Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01

  Formatted:  * dan
]]></artwork></figure>

<figure><artwork><![CDATA[
  Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01

  Formatted:  * dan
]]></artwork></figure>

</section>
<section anchor="clientinfo" title="CLIENTINFO">

<figure><artwork><![CDATA[
Type:   Extended Query
Reply:  CLIENTINFO <tokens>
]]></artwork></figure>

<t>This extended query returns a list of the CTCP messages that this client supports and implements, delimited by a single ASCII space.</t>

<t>CLIENTINFO is widely implemented. Clients SHOULD implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     CLIENTINFO
  Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
]]></artwork></figure>

</section>
<section anchor="dcc" title="DCC">

<figure><artwork><![CDATA[
Type:    Extended Query
Params:  DCC <type> <argument> <host> <port>
]]></artwork></figure>

<t>This extended query is used to setup and control connections that go directly between clients, bypassing the IRC server. This is typically used for features that require a large amount of traffic between clients or simply wish to bypass the server itself such as file transfer and direct chat.</t>

<t>The Direct Client-to-Client (DCC) Protocol requires its own specification, and is not described in-depth here.</t>

<t>DCC is widely implemented. Clients MAY implement this CTCP message.</t>

</section>
<section anchor="finger" title="FINGER">

<figure><artwork><![CDATA[
Type:   Metadata Query
Reply:  FINGER <info>
]]></artwork></figure>

<t>This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.</t>

<t>However, some implementations return the client name and version instead.</t>

<t>FINGER is largely obsolete. Clients MAY implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     FINGER
  Response:  FINGER WeeChat 1.8-dev
]]></artwork></figure>

</section>
<section anchor="ping" title="PING">

<figure><artwork><![CDATA[
Type:    Extended Query
Params:  PING <info>
]]></artwork></figure>

<t>This extended query is used to confirm reachability with other clients and to check latency. When receiving a CTCP PING, the reply MUST contain exactly the same parameters as the original query.</t>

<t>PING is universally implemented. Clients SHOULD implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     PING 1473523721 662865
  Response:  PING 1473523721 662865
  
  Query:     PING foo bar baz
  Response:  PING foo bar baz
]]></artwork></figure>

</section>
<section anchor="source" title="SOURCE">

<figure><artwork><![CDATA[
Type:   Metadata Query
Reply:  SOURCE <info>
]]></artwork></figure>

<t>This metadata query is used to return the location of the source code for the client.</t>

<t>SOURCE is rarely implemented. Clients MAY implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     SOURCE
  Response:  SOURCE https://weechat.org/download
]]></artwork></figure>

</section>
<section anchor="time" title="TIME">

<figure><artwork><![CDATA[
Type:    Extended Query
Params:  TIME <timestring>
]]></artwork></figure>

<t>This extended query is used to return the client’s local time in an unspecified human-readable format. In practice, both the format output by ctime() and the format described in Section 3.3 of <xref target="RFC5322"/> are common. Earlier specifications recommended to prefix the time string with a colon, but this is no longer recommended.</t>

<t>New implementations MAY default to UTC time for privacy reasons.</t>

<t>TIME is almost universally implemented. Clients SHOULD implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     TIME
  Response:  TIME Mon, 08 May 2017 09:15:29 GMT
]]></artwork></figure>

</section>
<section anchor="version" title="VERSION">

<figure><artwork><![CDATA[
Type:   Metadata Query
Reply:  VERSION <verstring>
]]></artwork></figure>

<t>This metadata query is used to return the name and version of the client software in use. There is no specified format for the version string.</t>

<t>Clients may allow users to customise the response value for this query.</t>

<t>VERSION is universally implemented. Clients SHOULD implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     VERSION
  Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
]]></artwork></figure>

</section>
<section anchor="userinfo" title="USERINFO">

<figure><artwork><![CDATA[
Type:   Metadata Query
Reply:  USERINFO <info>
]]></artwork></figure>

<t>This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.</t>

<t>However, some implementations return <spanx style="verb">&lt;nickname&gt; (&lt;realname&gt;)</spanx> instead.</t>

<t>USERINFO is largely obsolete. Clients MAY implement this CTCP message.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
  Query:     USERINFO
  Response:  USERINFO fred (Fred Foobar)
]]></artwork></figure>

</section>
</section>
<section anchor="change-history-rfc-editor-please-remove-this-section" title="Change History [RFC Editor: Please remove this section]">

<t>Changes from draft 0 (May 29, 2017)</t>

<t><list style="symbols">
  <t>Added note about servers truncating CTCP messages (thanks Peter).</t>
  <t>Fixed misspellings and added note to TIME about previously-recommended prefix (thanks Patrick).</t>
  <t>Mentioned how to parse/send empty ACTION messages (thanks dequis and the crew).</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAPHHbFkAA9Va624bR5b+z6coy1hAGpC0JcWxzThGFFpKtKPbSPIMduNg
XewukgU1u3q7iqQ4QYJ5i8G+zz7JPsl+51RVX0jdJtkMsAEcUs2qU+f6nUt1
r9frJCbV+WQg5m7ce9PpOO0yNRBbx7lTZa6cuFSZXInhVLqBGGZa5a7nTM9/
ExelcSYxmdgeXg8vdrY6cjQq1WIgji+H96/upCbJ5QzHpKUcu56RN5la9XSZ
9BKXFL2Xu52OnY9m2lpt8utVgZU6T1Wh8L/cdRLp1MSUK3o6NljrZJ7+h8xM
joUrZTuFHogfcFRXWFO6Uo0tvq1m/ktiZjNQsT92OvMiBSk7ELtfvHrbFXtv
dvc6HTl3U1MOOkL08E+I5zrHitO+ONU38+y//55L6597EU5l7qRd/7G1R8Wn
mzuqn0wJGxw3hKSHaiZ1NhCTUi61W30zoT/74L/ijY/50BfnrMHGGR9krlXW
fM4HQMXQvW0ST3nlN/4DlrB9WL3T6fV6Qo6sK2WCv66n2grsnJPmRKpsUuqR
ssJN1aNO0RXLqU6mIlPOijvcSmzDWXZEwputsJBfKIkNBtRLMVPWygmfhbUT
bE21LbBZpZBJlMoWBhpLhTNQh7CFSrTMxFKubF8QA2IKZY+UysVSpypbCT0r
MkWCqBS8aTcVM2NdzcC8KOA1CAqhHdTp9AK7+qKtAzN3mc7B1tQs+ehI1J8J
h2TleMrwOJPXksytSvudzrETwQHF5dGQfZD30R/kin1vhZlO00x1Os9JeaVJ
54lDVJBNFCiX6gGdFtES0EA0Wkpa+umnZziFTvz5Zz7TP6BT8cDk0BJpTQoL
NWSKJaBlY9b4ZJ7JkqSordNlKqmBLLlxdPACygYB2IF3Re1CVeo2mcp8ojh6
y5kkcWDUUiWO9PyYP9V6hEdVdCuiv8lfrsxMgZQkY1phxmxdNqj2ZqNPbCzV
f84VLBt3eznYZxqG7gqsKlfBkSOnpI2ZchKWl15tU5UV4EU7DWcQYw2FI+5y
O1al9Q7aotBfj8cJqd0ssIJcDshpITWYZ8Z98GG598J1/6fz/Y8FDDHC0Xxg
ZLZaS6J5z2660gjCZSkOjrx45pS4USuxNGVqxdbpx6vrra7/FGfn/P3y8E8f
jy8PP9D3q+8PTk6qL3HF1ffnH08+1N/qncPz09PDsw+8GVQP/m3LS7F1fnF9
fH52cLJFdnUtDUmECcw2Ip9DsBSlgvD3RMXe7i6iAnIg4k69JcXVCpB92+mw
BsioGhonopaos8ZI9ReXx38+vfqOs18IGc8b7ytVkW3ug1zHw8O4HDBDbplq
ynEIn+rAlXfeIlt1+aiRSVdkYwaZwOU2m18l8G9RyBKJALLuQOoJ8kTNJdME
EuqZxu8EbEocfHt2FOR/tbf/BUCA3JSVGKnzifhbkgtnmVnaQafzyy+/yFE+
RkJhgpRXvhb/cksZXFSogUe7f9imx3u9l2/FC/r2be/l0H877O0e8be93d7R
kdjh5NT87yuoELImDl6NMFeFE2cfT7r+xK4YXnbFyVHwAbFFB7PwVjx68K89
jo46OaKTWCleaq+AKPMP4uriAHYNrPyIB37Bj6Szzk8DuIFDhNz0ZKYn+ddb
CQVkuVU9pjz+9ZZlx9v6Ga7nCXv3SaRVPRhV5VZTfuqLv0yR4JJSSY7UXAXY
CuwQPnNZY0UIJ4CZx3mZFQBOhEmpEwEMpYRPuEP2V5JWjWsUYKwOIT7WOZCv
7UyR+ih4OMAQiXJiiKcKmDkdBLzRGQob+LW0Jg9JxJqxW5KQDBgyYQvoHDta
VEJRIZMbpOmQnSnk5xzphNvITwuSpE7N0ZVdOc8Tn3foxESVTiL+N0Cv2oAE
ohneIfufQvgDeSo5cSKln1xlNpgCgQbdNaGimXl8DPsntgkJIES/cMSTuJ4l
UUpOAEhpTDkeFpRQ7UAWQyIo9YRMA9sGkmD6lHx6UyGmICVQAtMZzEcnWuMz
JzsHUT4YEqx6Q0d9JODjIdmDLVCQd6mIouVuVQDUiCtsRNmLVMMJGdnZf0cu
iWKZQkFiE7OfrH6YmVRBmu8V9MWYvjStdN3GZ5g2YK5HKsTrANGWqGfym8yA
mSlVZxG0R2YkBp8AXX8+vLyCxPSVduD5s1FjfQBsJtTaIK5yecPefSoT8UV/
d/9TAMIHTn2Oknyx7+lcHJ99hzLw9T4g+PXbL8Xb3Tf7ey+fzscD+0n6ZkKj
psqGfFaF1ETl0DuZyMkbxcGbq5Bk4MyO9nC6sHXO4Ydsi1QBERRVMz7ZWnIz
PV6JOZy+5B4N/uVjHOvz//nbf1FtNkaVQ/WFdN4HyOWqulU7q7Ix5+Ln4vDW
KY6futoKlRAxUZk/VmqPlGljuBWVsL2Ftlz3BIlIQLi/BhqRENSN3L3Qh4md
mnmWkk/XZWYlFDQ5Ls2sKpkrTfeE6k/6lEoRGZIL+i4VyxAGrt/lp3lugFIc
p1DAHcLX5Cr44Jo9uFalaUQI5HdeJWDU17F5FbW0a6ky7hJGyi2pVYqlJlkb
FDSV9ZRCDJXrSYVcHq8aRQJZokuEtPObwFPApjwWMD5/WPUI/x6aoYmpXKi6
noFdRnMXfBU1Um4qqoceCepgR1P7bP5I0AV4W5aaGjFLDQC5i33WjBsKHF+x
C4L/1SN+F9ufEg2Zbx+Fday4ZssjR8iN7O9OlpOql+n6zoqTJOyTVCkXB/BB
FJy+9SZa3pO9itngtXG2N9TpMaPLS4gysbbTFx/qpDlip6MkQeUIXDN0yPPM
6YI6Qe8YnMBgtRnaO9KZ0zAmOVe1sE5uoBwgmRJR1GNE6dgWcLBqgg7OjIku
dMgudbriJEaKVQiwBJl6e6RWVO1SmFJE+L0FNTmMHDtfCT2OZXSdvObEVosQ
gAetAAoxzld1UIdRk/6rbxfgjSoGolc5ijCnZHqXZKlh/2f3Jc7XXdiHJRuM
OGY912vouGaRIIj2XU7+u2Y0OVIlDxT2XvdftSOiQqR/JCLSFeratTiAp+t8
YZBxPBJaD5pc57C3/b7eX1d0sZyp6w2Z0VygBpui1Av6DGVFE5fvqDo4OtbQ
61da8J9XGmxUBVD1DLG0CDhNLs3JXJbIeCqNA5swcEHkKihWKM0V6zyvkk9F
EPa+yc2yMRBj128sXcgMeTs2E4hK43FhxtoteAgWkL+Zh1SFA4SgNWNUqUe+
Zp6U9LVNtb9QYaBF5Vt0KFDkGhpNfGgr1mEQEMFVugdqKmDUVJMb5jwDCGDq
ZwkHCUmNSnfCYGbJqWV+YyPv2ICcNCnNvGAuJnpBtMdKpSPqckworLmYGWvf
v/gkDwp/nMrMVwdCpguyu4lZXIwzY1htrpFN4tGn6CAkXP0KhEpEE3dnsY8k
T+iK69KsxCX1/O1fPTxlXLl9GA6rsq3brCj+mAFuxb+r+UQxr9+iuoCrSSoK
UfAYZF7jVAibBXlURbMlKUXOVajjXMV9SkkDeHpBwSUujD8VtP5VUkJCO0I+
S1zzkC3MQHQMU38O9dveRlcqmZfUkQ5xIPCq9EevhwS34IaC2FFun+doKC1R
qmd60UGq9CatRZPtg4Qdi4gQuz3CMd8LRZpg5pzHanxsWw3VyApOakIZiM4+
jR1xzdstM0Lxujn47ovjVk9fBRuxWifcrcwse5kCUMbTtojPLeJr/fmSWj8A
nW2Wpk+TBN19NufAbYdnK21rtkg9k44YCX7WZ2hPko3dIOYQPiky3ypfve56
Dd2xWgnagR7AAyqlwW97RuLtHNpkFkpJq6kfoFgka4/HAbHKMLhdBdNFKOG+
PQwOuY2xkZ4cxbTqIzv62pNoVqhIEgRopTac7w5o3mUt4WQ1cKkO91ncccky
kVT3sAp94BwfnB1sBE17Sk0XCtRExByPQ2kX7adrDsK4Vot6om28ebIet6JJ
1O0UmEL528cajyoyzUwi/7X9phkXm3EAdkpjbQRgoRJjVwjlWRhy+dJMNgeq
wt/7jBRig8doMra6mjCLB3YxFxZwEVb2Qpaaxhxcadp5CZSvKtZZmHKwV49Q
c98oZ0PP67sTXyn4i1D8V9UcR3UjfMFzRvwc+pl3DoXqe5/cWYfq/gaS6t1l
yN+feOOn93c2tlxRwehl2kPCtCb2ruRAagbf+ErUYzSqpNHjN8cKtHrhITcO
o+O89POLmfpMl2LjmgXiela4Vbfy8BDIsD1g3qNGAxFsIZH35JiM9Nnr4bPY
1n309FS4E6k4jw0etcNtD2WG1kCyDpJwYGJKfz3FGNGIjqDtdiUDbdBn7O7a
R0LGsInK41zTRI6Vs44wCypBqkubeavU4qyyBmUtsKRrNm5tfPdJbgr3rovP
eiJ2KZeDOPr2DTPg45vH2mW+6dPuWZxwBU9UKWj9ge6UqxXeBX/LWfee8ZtJ
P0KZAnB4cnx4dn18dnTeDsK17ueScALP6+WIQLQ0ub0zBn19WSo3L3OKKQKv
eJuzXn3LYN9QzIXraV/BVC5gu9UQnqdoVUwcXA2Pj31kUDqp2dP2zrJgzfEf
8LE7OhnWhTdDQ28wTiiz2woK5qXKsfGUO5Xr49NDEZrQ2hZYeR8SeitUIEg0
31Ev+l68k+WEExC+kjvgg/T3gFkabauFhQpfzxm6fM8aM5l4w2yqu+v16Rna
/FWBui/WypRgfG6u7yvqsTifSVlxjPJ6XqqqofJjETgJTYmEnCF1eGcp5RjF
1PqpBD+ckGikYKc89GM2mrWBH4/AmSgz2vads7/KZ5moEXYhFX7wTzau57eh
7J36kj7wS7EPVpb5Xf1KyOPNy9deqgpAJw2VcB7Z7xEHpabuYe8klzmCNx1e
tr1mbZQXQ9cvFe9oNNH0jllzrlMH7UzbBNW7zJWZW55nNAZ6BD7dhm1Z8ygf
WnMPMi8nSCSg1N9ZK00zUpnR5R+Mgud024GuZkH0eDip12pbz09jWsJvAMUM
YrlsqmZUQUZIxc4EzszIGm45/gHFPhD2Qd+tkA+H/kUpniTt9t/A2Is6rCni
nxjXDA4bFro/fhGtY13SAF7Ck8Nt4+YbFbGJTqYKjTY1hXmyCpdZfnDAbYHX
A/EQ7+8oyDgXEzzQFaK6lYwElcE3B3rxfs5zC3WyUPcXA/93mNwaAu3tii+/
3Hvz5au2se5dcwepsQG0yBL//noHkeavla2vzj9eDg+fFI9+6aPx2LruqUKB
ZmG+Mg0tkZmXCVWbqQpvNjSGi+EkUCrRJfx6wHlA9UHulpbCsVPnCjt48QIY
zmhrysmLFMCZGZnWiqOM+MQg4eT5jifyjq50nxYqGzjC0MQzRUG0Qps7zwOe
003fHKV7D7GVUmsTGgt03zkaRSr1E/RnIxMKff8rvQ5QACTpspeobu9Ur8qF
Ba03cq5C47ff3ydLhhdU9vfoLbUw6EB53BeHsgTP5fqAAbHLL3umcQitxvrW
37iQRF491R2zySg/jeauusBGu4pnE1U2KcHQZ2q5gcPkHqkaS5oI4KyP10N/
CHkbj42T6j0HSqhkIxpDZfyG4O8e+uw+Le9jDk5J4pdvxCl6/72Xu6/Fy7eD
3VeDvbfiu9Pr2vliJfaUsI1XB+9IoA3/e1LwbiSwEMSxAo4viMBBsLt9R1l7
Z/CnGO2RlueJauHGHERmoZkvec6RzK1Df2fjZVQYEvNYun4xKuJ3lPifAeHR
Ei1TRgbWMqzYnmg3EIvd/uve/t7b3mRvb7w3Tl/uy53atB+vDi83u5t7bBsX
/38tkj6/y3VyQ/vei+13kcb7nc+NEqmS8fcrkiqdt6xYHTwu4b3bRyUPeAxS
aDDXc3q1l15x/R7dooGWP/1Arwofphp/DcRFxq9rlWpmFipcFXj4/PQjvJ23
hqs1fu1evBTbHPf05jtif6fT6YmDlLAy54k8Gyq+MxRfmYqvgVYN6nYYxvME
fqcPGkf6lq57tEUsZhl2+PpK1qQRYgw//oiC5v7wj2zVawJ2QOuKvkTgJjd8
wim9MGL4ZRP/9jVPZV74V8d5zLM+l4lU/H1BlXOSUi1B8X8BDo7r6AgxAAA=

-->

</rfc>