From 7b53988278f9c64ee1b45aea8753206c2009a0dd Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 2 Dec 2013 18:33:55 -0700 Subject: [PATCH] 0.0.2 --- inbox/eventlogging.xml | 301 +++++++++++++++++++++++------------------ 1 file changed, 173 insertions(+), 128 deletions(-) diff --git a/inbox/eventlogging.xml b/inbox/eventlogging.xml index bee46c83..eeb66a1f 100644 --- a/inbox/eventlogging.xml +++ b/inbox/eventlogging.xml @@ -8,15 +8,7 @@
Event Logging over XMPP This specification provides a common framework for sending events to event logs over XMPP networks. - - This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF). - Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. - ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## - In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. - - This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). - - + &LEGALNOTICE; xxxx ProtoXEP Standards Track @@ -28,7 +20,7 @@ - eventlog + eventlogging Peter Waher @@ -36,6 +28,14 @@ peter.waher@jabber.org http://www.linkedin.com/in/peterwaher + + 0.0.2 + 2013-12-02 + pw + +

Addressed pre-publication feedback from the XMPP Council.

+ + 0.0.1 2013-11-10 @@ -56,10 +56,16 @@ analyze it accordingly.

- 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 + 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 such an XML format. This format is able to store Syslog RFC-5424: The Syslog Protocol <https://tools.ietf.org/html/rfc5424> - compliant event information, even though the Syslog event model has been somewhat extended. + compliant event information, even though the Syslog 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 Syslog specification. +

+

+ 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 Security Considerations section.

@@ -103,7 +109,7 @@
Stack Trace
- Exact position in the code from whice the event was reported or error occurred. Reporting it in a separate attribute unclutters the message, and removes the need + 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 to define custom tags.
@@ -122,126 +128,139 @@ - +

- The following example shows how to send a simple event using a normal message to an event log. There are only two parameters that are required: - message and timestamp. This message will be treated as a Minor Informational message by the - recipient. + The following example shows how to send a simple event using a normal message to an event log. Only two parameters are required: + The timestamp of the message goes into the timestamp attribute, and the actual messages goes into a child element + named message. This event will be treated as a Minor Informational event by the recipient.

- + + Something happened. + ]]> - + +

+ The following example shows how to send a multi-line event. +

+ + + + 10 objects deleted: +Object 1 +... +Object 10 + + ]]> + + +

The following example shows how an event message can be categorized with an event type and level.

- + + Low on memory. + ]]> - +

The following example shows how an event message can be further enhanced by providing object and subject information.

- + + Object deleted. + ]]> - +

- The following example shows how an event message can receive an ID that can be singled out later to be analyzed by administrators, for instance. + 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.

- + + User attempted to login but provided incorrect password. + ]]> - +

The following example shows how to tag an event using custom information in a way that is easy to interpret and process.

- - - - + + Current resources. + + + ]]> + Note: Any tag elements must come after the message element. - +

- The following example shows how module information can be provided in events to more easilly be able to single out information + The following example shows how module information can be provided in events to more easily be able to single out information relating to the same application running on different machines.

- + + Something horrible happened. + ]]> - +

- The following example shows how to send a debug message with a stack trace, module and custom inforation. + The following example shows how to send a debug message with a stack trace, module and custom information.

- - - - + + Something is rotten in the state of Denmark. + + + + File1, Line1, ... +File2, Line2, ... +... + + ]]> + + Note: Any stackTrace element must come after the message element and any tag 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. +

+ + + + Something happened. + + + Something else happened. ]]> @@ -277,10 +296,10 @@

- +

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 Informational. - It is largely based on the severity levels of Syslog. + It is largely based on the severity levels of Syslog.

@@ -309,7 +328,7 @@ - + @@ -321,7 +340,7 @@
CriticalA ciritical condition. An error so great that it could escalate into something graver if not addressed.A critical condition. An error so great that it could escalate into something graver if not addressed.
Alert
 - +

Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).

@@ -340,67 +359,64 @@ Major - More substantial events or affecting larger parts of the system. + More substantial events or events that are affecting larger parts of the system. - +

- Using Event IDs the application can provide a machine understandable classification of the event. Examples could be "Login"-events, "ConnectionProblem"-events, etc. + 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 - to more easilly extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable). + to more easily extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).

-

- Note: To avoid problems when running applications using different locales, event IDs should never be localized. -

- -

- An event is often linked to an object, i.e. on which object an action was performed, or which object is reporting a condition. The object field permits + Note: To avoid problems when running applications using different locales, event IDs should never be localized. +

+ + +

+ 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 the tagging of objects in a common way. It is later easy to extract all events relating to a specific object by using this attribute.

- +

An event is often also linked to a subject, i.e. who or what performed a given action resulting in the event or condition. The subject field permits - the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subbject by using this attribute. + the tagging of subjects in a common way. It is later easy to extract all events relating to a specific subject by using this attribute.

- +

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 Syslog, and leaves it open. However, it is left as a special attribute since it is important in monitoring applications. + other protocols such as Syslog, and leaves it open. However, it is left as a special attribute since + it is important in monitoring applications.

- +

A module is part of a larger software package. Using the module attribute makes it easier to attribute events to specific parts of a distributed application and analyze them separately.

- +

Stack Traces can be important information to developers and correlate events to actual locations in the code that generated the event. This document does not specify any particular format for stack traces.

-

- Note that stack traces can be divided into multiple lines separated by CRLF. It is important to encode such strings correctly to avoid problems in - XML parsers. -

- +

- Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a datatype. - Data Types are specified using Qualified Names (QNames). If possible, they should adher to the list of + Any event can have a custom set of tags attached to it. A tag is required to have a name and a value. It can also optionally specify a data type. + Data types are specified using Qualified Names (QNames). If possible, they should adhere to the list of Data Forms Validation Datatypes Data Forms Validation Datatypes <http://xmpp.org/registrar/xdv-datatypes.html> that is maintained by the XMPP Registrar.

-

- Note: To avoid problems when running applications using different locales, tag names should never be localized. -

+

+ Note: To avoid problems when running applications using different locales, tag names should never be localized. +

- +

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 @@ -408,13 +424,20 @@ databases because of devices implemented by third parties.

- It is still valid to send such information (like sequence numbers, unique GUIDs, resource names in JIDs etc., measurements, etc.) in tags names and values, but should be avoided in - event IDs, objects, subjects, facilities and modules, as they can cause problems further down the line. + 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. +

+ + +

+ 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.

@@ -426,22 +449,44 @@ If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.

- +

Event messages SHOULD contain an xml:lang attribute on the message stanza to specify the language - used in message texts, etc. If language information is not available (for instance, if relaying messages not created by the device itself, - the xml:lang attribute can be omitted). + used in message texts, etc. If language information is not available, e.g. if relaying messages are not created by the device itself, + the xml:lang attribute can be omitted.

-

- 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. -

-

- Never log information that should be handled securely or encrypted, such as passwords. -

+ +

+ 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. +

+ + +

+ Never log information that should be handled securely or encrypted, such as passwords. +

+ + +

+ The following subsections lists different transport options together with security considerations for each one. +

+ +

+ This document explicitly describes how to send event messages in direct messages. If sensitive information is being sent, + end-to-end encryption should be considered. +

+ + +

+ Event messages could be published using Publish-Subscribe. But, even more care should + be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern + should be avoided. +

+ +

This document requires no interaction with &IANA;.

@@ -463,16 +508,17 @@ - - + + + - - + + @@ -481,7 +527,6 @@ - @@ -509,7 +554,7 @@ ]]> - -

Thanks in alphabetical order to Joachim Lindborg, Markus Kohlhase, Matthew Wild, Mike Taylor, Robert Kosten, Steffen Larsen, and Yusuke DOI for all valuable feedback.

- - \ No newline at end of file + +

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.

+ +