<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Incident Reporting</title>
  <abstract>This specification defines methods for incident reporting among XMPP server deployments.</abstract>
  &LEGALNOTICE;
  <number>xxxx</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  <discuss>operators</discuss>
  <author>
    <firstname>Artur</firstname>
    <surname>Hefczyc</surname>
    <email>artur.hefczyc@gmail.com</email>
    <jid>artur.hefczyc@tigase.org</jid>
  </author>
  <author>
    <firstname>Florian</firstname>
    <surname>Jensen</surname>
    <email>admin@flosoft.biz</email>
    <jid>admin@im.flosoft.biz</jid>
  </author>
  <author>
    <firstname>Mickaël</firstname>
    <surname>Rémond</surname>
    <email>mickael.remond@process-one.net</email>
    <jid>mremond@process-one.net</jid>
  </author>
  &stpeter;
  <author>
    <firstname>Matthew</firstname>
    <surname>Wild</surname>
    <email>mwild1@gmail.com</email>
    <jid>mwild1@jaim.at</jid>
  </author>
  <revision>
    <version>0.0.3</version>
    <date>2009-04-30</date>
    <initials>psa</initials>
    <remark><p>Per Council feedback, moved server rosters to a separate specification.</p></remark>
  </revision>
  <revision>
    <version>0.0.2</version>
    <date>2009-04-27</date>
    <initials>psa/fj</initials>
    <remark><p>Refactored XML format; added elements for sub-categories, locations, related incidents, solutions, and suggestions.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2009-04-13</date>
    <initials>ah/fj/psa/mr/mw</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>
  <p>As XMPP technologies have been deployed more widely, the open XMPP network has become a more significant target for attacks. This specification defines ways for XMPP server deployments to share information with each other and therefore handle such attacks in a more real-time fashion. In particular, it defines a format for sharing incident reports among XMPP server deployments. (For some related considerations, see &rfc2350;, &rfc3067;, and &rfc5070;.)</p>
</section1>

<section1 topic='Incident Reports' anchor='reports'>
  <p>An incident report consists of an XMPP &MESSAGE; stanza containing an &lt;incident/&gt; child element that includes an 'id' attribute whose value is a UUID as described in &rfc4122;. An example is shown below. A server deployment SHOULD send incident reports only to peer servers that it trusts, for example peers that are in its "server roster".</p>
  <example caption="An incident report"><![CDATA[
<message from='jabber.org' to='im.flosoft.biz'>
  <incident xmlns='urn:xmpp:incident:0'
            id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
    <description>
      <discuss>
        <admin>stpeter@jabber.org</admin>
        <muc>operators@conference.jabber.org</muc>
      </discuss>
      <info>
        <category>muc</category>
        <type>presence</type>
        <type>long-messages</type>
      </info>
      <locs>
        <loc>jdev@conference.jabber.org</loc>
        <loc>jabber@conference.jabber.org</loc>
      </locs>
      <rels>
        <rel>133BCE2E-E669-4ECE-B0F8-766B9E65630D</rel>
      </rels>
      <severity>2</severity>
      <source>
        <ips>
          <ip>192.0.2.1</ip>
        </ips>
        <jids>
          <jid>abuser@abuse.lit</jid>
          <jid>loser@abuse.lit</jid>
        </jids>
      </source>
      <text xml:lang='en'>lots of MUC spammers from abuse.lit!</text>
      <time>
        <begin>2009-04-13T19:05:20Z</begin>
        <end>2009-04-13T19:27:22Z</end>
        <report>2009-04-13T19:31:07Z</report>
      </time>
    </description>
  </incident>
</message>
  ]]></example>
  <p>The defined children of the &lt;description/&gt; element are as follows:</p>
  <table caption='&lt;description/&gt; children'>
    <tr>
      <th>Element Name</th>
      <th>Description</th>
    </tr>
    <tr>
      <td>&lt;discuss/&gt;</td>
      <td>This element contains the JID of the server admin who generated the incident report (&lt;admin/&gt;), as well as a &xep0045; room where the incident can be discussed (&lt;muc/&gt;).</td>
    </tr>
    <tr>
      <td>&lt;info/&gt;</td>
      <td>Structured information about the incident. The defined values of the &lt;category/&gt; and &lt;type/&gt; elements shall be provided via a registry. It is envisioned that the &lt;category/&gt; values shall be "muc" for &xep0045; incidents, "pubsub" for &xep0060; incidents, "reg" for account registration (&xep0077;) incidents, and "stanzas" for general XMPP traffic incidents.</td>
    </tr>
    <tr>
      <td>&lt;locs/&gt;</td>
      <td>The place or places on the XMPP network where the incident has occurred (such as a multi-user chat room, a publish-subscribe service, or a general XMPP server), each contained in a separate &lt;loc/&gt; element.</td>
    </tr>
    <tr>
      <td>&lt;rels/&gt;</td>
      <td>The IDs of one or more incidents to which this incident might be related, each contained in a separate &lt;rel/&gt; element.</td>
    </tr>
    <tr>
      <td>&lt;severity/&gt;</td>
      <td>The seriousness of the problem, from 5 (least serious) to 1 (most serious).</td>
    </tr>
    <tr>
      <td>&lt;source/&gt;</td>
      <td>The IP address(es) and JabberID(s) where the incident originated.</td>
    </tr>
    <tr>
      <td>&lt;text/&gt;</td>
      <td>A natural-language description of the event. This element SHOULD possess an 'xml:lang' attribute. Multiple &lt;text/&gt; elements MAY be included, each with a different 'xml:lang' value.</td>
    </tr>
    <tr>
      <td>&lt;time/&gt;</td>
      <td>The time when the incident began and ended (include an empty &lt;end/&gt; element if the incident is still happening) and, optionally, was reported. The dates MUST conform to the DateTime profile specified in &xep0082;</td>
    </tr>
  </table>
</section1>

<section1 topic='Incident Solutions' anchor='solutions'>
  <p>If the reporting entity determines a solution to the problem, it MAY send out a revised incident report containing a &lt;solution/&gt; element.</p>
  <example caption="An incident solution"><![CDATA[
<message from='jabber.org' to='im.flosoft.biz'>
  <incident xmlns='urn:xmpp:incident:0'
            id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
    <description>
      ...
    </description>
    <solution>
      <text xml:lang='en'>banned the offenders</text>
    </solution>
  </incident>
</message>
  ]]></example>
  <p>Further definition of the &lt;solution/&gt; element will be provided in a future version of this specification.</p>
</section1>

<section1 topic='Incident Suggestions' anchor='suggestions'>
  <p>If an entity that receives an incident report has a suggested solution to the problem, it MAY send an incident message containing a &lt;suggestion/&gt; element.</p>
  <example caption="An incident solution"><![CDATA[
<message from='im.flosoft.biz' to='jabber.org'>
  <incident xmlns='urn:xmpp:incident:0'
            id='BA51A035-7710-4558-9BBF-34838A4C5B24'>
    <suggestion>
      <text xml:lang='en'>here is how we solved the problem...</text>
    </suggestion>
  </incident>
</message>
  ]]></example>
  <p>Further definition of the &lt;suggestion/&gt; element will be provided in a future version of this specification.</p>
</section1>

<section1 topic='Security Considerations' anchor='security'>
  <p>To follow.</p>
</section1>

<section1 topic='IANA Considerations' anchor='iana'>
  <p>To follow.</p>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>To follow.</p>
</section1>

<section1 topic='XML Schema' anchor='schema'>
  <p>To follow.</p>
</section1>

</xep>
