This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
to analyze the status or operation of the network and its participants.
</p>
<p>
The basic principle behind interoperable event logging over XMPP is the definition of a common XML element defining the event. This payload is then sent in
a normal message stanza (i.e. with <strong>type='normal'</strong>) to the recipient. The recipient in turn, if it understands the payload, can choose to store it in an event log, forward it or
There are various event log packages available, but none yet defined for XMPP or using a well-defined and known XML format. Therefore, this document defines
</note> compliant event information, even though the <linkurl='https://tools.ietf.org/html/rfc5424'>Syslog</link> event model has been somewhat extended.
Also, in the use of the facility attribute, this XEP does not have the same restrictions compared to the <linkurl='https://tools.ietf.org/html/rfc5424'>Syslog</link> specification.
</p>
<p>
This document does not restrict the use of event messages to directed message stanzas alone. It may be envisioned that some would like to publish event information through
&xep0060; or other mechanisms. It is not in the scope of this document to specify such transports however, as it only deals with direct messages, but a brief list is provided
in the <linkurl='#transportoptions'>Security Considerations</link> section.
<p>The following table lists common terms and corresponding descriptions.</p>
<dl>
<di>
<dt>Event</dt>
<dd>A piece of information describing an event in time.</dd>
</di>
<di>
<dt>Event ID</dt>
<dd>An attribute providing a machine readable ID to the type of event in question without having to parse the message text itself.</dd>
</di>
<di>
<dt>Event Level</dt>
<dd>Provides an additional level on the previous classification (Minor, Medium, Major).</dd>
</di>
<di>
<dt>Event Type</dt>
<dd>Coarse classification of the event (Debug, Informational, Notice, Warning, Error, Critical, Alert, Emergency).</dd>
</di>
<di>
<dt>Facility</dt>
<dd>What type of device, server, application, etc., is sending the message. </dd>
</di>
<di>
<dt>Message</dt>
<dd>A (human readable) text message describing what has occurred.</dd>
</di>
<di>
<dt>Module</dt>
<dd>
The module reporting the event. Larger software packages are often divided into modules. Keeping track of which modules report which events can be useful when
analyzing system performance.
</dd>
</di>
<di>
<dt>Object</dt>
<dd>The object to which the event message refers to, on which the current action is performed.</dd>
Exact position in the code from which the event was reported or where the error occurred. Reporting it in a separate attribute unclutters the message, and removes the need
The following example shows how to send an event message with an event ID that can be singled out later to be analyzed by administrators, for instance.
<strong>Note:</strong> Any <strong>stackTrace</strong> element must come after the <strong>message</strong> element and any <strong>tag</strong> elements.
The following example shows how multiple events can be sent in a single message. The receiver should interpret this as two different events having been received.
<p>If an entity supports the reception of events as specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:eventlog" in response to &xep0030; information requests.</p>
<examplecaption="Service discovery information request">
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
The following table lists possible event types that can be used. If none is specified for an event, it is assumed that the event is <strong>Informational</strong>.
Using Event IDs, the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc.
It is easier to group, parse or interpret events and their tags if you know what type of event it is. Event IDs are manufacturer specific, and only provide a means
<strong>Note:</strong> To avoid problems when running applications using different locales, event IDs should never be localized.
</p>
</section2>
<section2topic='Object'anchor='object'>
<p>
An event is often linked to an object, e.g. on which object an action was performed, or which object is reporting a condition. The object field permits
Facility can be either a facility in the network sense or in the system sense. This document does not restrict its use to the possible choices defined by
other protocols such as <linkurl='https://tools.ietf.org/html/rfc5424'>Syslog</link>, and leaves it open. However, it is left as a special attribute since
If persisting received events in a database, care should be taken if normalized tables are used for storage of tags names and values, event IDs, objects, subjects,
facilities and modules. If this is the case, the receiver should look for types of values that can be incompatible with normalized tables (such as floating point values or numbers
in general, GUIDs, resource names in JIDs etc.) and replace them with some descriptive text and append the corresponding value in the message text instead. This to avoid problems with indexes in
databases because of devices implemented by third parties.
It is still valid to send information like sequence numbers, unique GUIDs, measurements, resource names in JIDs etc. in tag names and values, but such information
should be avoided in event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line.
</p>
</section2>
<section2topic='Multi-line messages and stack traces'anchor='multilinemessagesstacktraces'>
<p>
The messag text and stack trace parts of an event message lie as simple type valued child elements (xs:string). This allows for simple encoding of multi-line text
information into these two parameters. However, do not indent new lines when serializing multi-line text to these parameters to make the XML look nicer. The recipient
cannot know what whitespace is indenting and what is part of the actual information.
All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.
</p>
<p>
<strong>Note:</strong> If time zone is not available, it is supposed to be undefined. The recipient of an event message without time zone information
should assume the sender has the same time zone as the received, if not explicitly configured otherwise on the recipient side.
</p>
<p>
If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.
Even though this document permits zero-configuration of devices to event logs, this might not always be the best option. Event information might be sensitive
and should not be sent to anybody just because they support the event log feature as defined in this document.
The <linkurl="#schema">protocol schema</link> needs to be added to the list of <linkurl="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
<p>Thanks in alphabetical order to Dave Cridland, Joachim Lindborg, Karin Forsell, Ludovic Bocquet, Markus Kohlhase, Matthew Wild, Mike Taylor, Philipp Hancke, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.</p>
