<abstract>This specification defines methods for incident reporting among XMPP server deployments using the IODEF format produced by the IETF's INCH Working Group.</abstract>
<remark><p>Aligned document with the IETF guidelines for defining extensions to IODEF; defined several more IODEF NodeRole categories; added schema for the JID element; noted that the JID element might be moved to a separate specification.</p></remark>
<remark><p>Simplified the processing model to send reports only in IQ-sets (not in IQ-results); filled out the sections on inquiries, requests, and responses; corrected the schema and examples.</p></remark>
<remark><p>Added more detailed information about the solution element; removed the suggestion element since the solution element can be used by both reporting entities and receiving entities; added notes about processing of incident reports by receiving entities.</p></remark>
<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 to handle such attacks in a more real-time fashion. In particular, it defines a way to use the IODEF format (defined in &rfc5070; and produced by the IETF's INCH Working Group) as the basis for sharing incident reports among XMPP server deployments. (For some related considerations, see &rfc2350; and &rfc3067;.)</p>
<p>This document defines several interactions (similar to those in RID, see &rfc6045;) between XMPP server deployments with respect to incident handling. These interactions are transported using the XMPP &IQ; stanza as described below, where each element (qualified by the 'urn:xmpp:incident:2' namespace) is used as a wrapper for IODEF data.</p>
<li><p>The <report/> element (contained in an &IQ; stanza of type "set") describes the nature of an incident and also flags the 'status' of the incident as "new", "updated", or "resolved"; it is sent from one server to another for informative purposes but without requesting assistance (for which see the <request/> element). This element is similar to a RID message type of "Report".</p></li>
<li><p>The <inquiry/> element (contained in an &IQ; stanza of type "get") asks for information about an incident; it is expected that the reply will contain a <report/> element. This element is similar to a RID message type of "IncidentQuery".</p></li>
<li><p>The <request/> element (contained in an &IQ; stanza of type "get") asks for assistance in resolving an incident, e.g., by requesting that the server take some action. This element is similar to a RID message type of "Investigation" or "TraceRequest".</p></li>
<li><p>The <response/> element (contained in an &IQ; stanza of type "set") provides assistance in resolving an incident. This element is similar to a RID message type of "Result".</p></li>
<p>When one server wants to send information about an incident, it sends a incident report to another server. The report consists of an XMPP &IQ; stanza of type "set" containing a <report/> element that in turn contains an IODEF document. An example is shown below.</p>
<p>If the recipient is able to process the report, it MUST return an &IQ; stanza of type "result"; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).</p>
<p>When one server wants to find out more information about an incident, it sends an inquiry to another server (not necessarily the server where the incident occurred).</p>
<examplecaption="An inquiry about an incident"><