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.
This document defines several interactions (similar to those in &rfc6045;) between XMPP server deployments with respect to incident handling. These interactions are transported using the XMPP &IQ; stanza as described below.
+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.
The <report/> element (contained in an &IQ; stanza of type "set" or, in response to an <inquiry/> element, of type "result") 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 (sometimes in reply to the <inquiry/> element) but without requesting assistance (for which see the <request/> element).
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.
The <request/> element (contained in an &IQ; stanza of type "get") asks for assistance in resolving an incident.
The <response/> element (contained in an &IQ; stanza of type "result") provides assistance in resolving an incident.
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".
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".
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".
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".
An incident report consists of an XMPP &IQ; stanza of type "set" or "result" containing an IODEF document. An example is shown below.
-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.
+If the report is contained in an &IQ; stanza of type "set" and the recipient of the report is able to process it, it MUST return an &IQ; stanza of type "result". Error handling will be defined in a future version of this specification.
+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).
To follow.
+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).
+If the recipient is able to process the inquiry, it MUST return an &IQ; stanza of type "result" and then send a report about the incident using an &IQ; stanza of type "set" as defined above; if not, it MUST return an &IQ; stanza of type "error" (error handling will be defined in a future version of this specification).
To follow.
+When one server wants to ask for assistance in resolving an incident, it sends a request to another server (not necessarily the server where the incident occurred).
+Here, the server where the attack occurred requests that the server where the attack originated will disable the offending accounts (via the "block-host" value for the 'action' attribute of the IODEF <Expectation/> element).
+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).
To follow.
+When one server provides assistance in resolving an incident, it sends a response to another server (not necessarily the server where the incident occurred).
+Here, the server where the attack originated informs the server where the attack occurred that it has disabled the offending accounts (via the IODEF <HistoryItem/> element).
+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).