-
Notifications
You must be signed in to change notification settings - Fork 13
/
Copy patheventlogging.html
756 lines (740 loc) · 47.8 KB
/
eventlogging.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>XEP-0337: Event Logging over XMPP</title>
<link rel="stylesheet" type="text/css" href="xmpp.css">
<link href="prettify.css" type="text/css" rel="stylesheet">
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico"><script type="text/javascript" src="prettify.js"></script><meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=2.0">
<meta name="DC.Title" content="Event Logging over XMPP">
<meta name="DC.Creator" content="Peter Waher">
<meta name="DC.Description" content="This specification provides a common framework for sending events to event logs over XMPP networks.">
<meta name="DC.Publisher" content="XMPP Standards Foundation">
<meta name="DC.Contributor" content="XMPP Extensions Editor">
<meta name="DC.Date" content="2014-01-08">
<meta name="DC.Type" content="XMPP Extension Protocol">
<meta name="DC.Format" content="XHTML">
<meta name="DC.Identifier" content="XEP-0337">
<meta name="DC.Language" content="en">
<meta name="DC.Rights" content="This XMPP Extension Protocol is copyright © 1999 - 2013 by the XMPP Standards Foundation (XSF).">
</head>
<body onload="prettyPrint()">
<h1>XEP-0337: Event Logging over XMPP</h1>
<table>
<tr valign="top">
<td><strong>Abstract:</strong></td>
<td>This specification provides a common framework for sending events to event logs over XMPP networks.</td>
</tr>
<tr valign="top">
<td><strong>Author:</strong></td>
<td>Peter Waher</td>
</tr>
<tr valign="top">
<td><strong>Copyright:</strong></td>
<td>© 1999 - 2013 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td>
</tr>
<tr valign="top">
<td><strong>Status:</strong></td>
<td>Experimental</td>
</tr>
<tr valign="top">
<td><strong>Type:</strong></td>
<td>Standards Track</td>
</tr>
<tr valign="top">
<td><strong>Version:</strong></td>
<td>0.1</td>
</tr>
<tr valign="top">
<td><strong>Last Updated:</strong></td>
<td>2014-01-08</td>
</tr>
</table>
<hr>
<p style="color:red">WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.</p>
<hr>
<h2>Table of Contents</h2>
<div class="indent">
<p><br>1. <a href="#intro">Introduction</a><br>2. <a href="#glossary">Glossary</a><br>3. <a href="#usecases">Use Cases</a><br>
3.1. <a href="#simpleevent">Sending a simple event message</a><br>
3.2. <a href="#multilinemessage">Sending a multi-line event message</a><br>
3.3. <a href="#typelevel">Specifying type and level</a><br>
3.4. <a href="#objectsubject">Specifying object and subject</a><br>
3.5. <a href="#eventids">Specifying an event ID</a><br>
3.6. <a href="#tags">Tagging events with custom information</a><br>
3.7. <a href="#modules">Specifying program module</a><br>
3.8. <a href="#debug">Sending debug information</a><br>
3.9. <a href="#multipleevents">Sending multiple events</a><br>4. <a href="#support">Determining Support</a><br>5. <a href="#impl">Implementation Notes</a><br>
5.1. <a href="#eventtype">Event Type</a><br>
5.2. <a href="#eventlevel">Event Level</a><br>
5.3. <a href="#eventid">Event ID</a><br>
5.4. <a href="#object">Object</a><br>
5.5. <a href="#subject">Subject</a><br>
5.6. <a href="#facility">Facility</a><br>
5.7. <a href="#module">Module</a><br>
5.8. <a href="#stacktrace">Stack Trace</a><br>
5.9. <a href="#tag">Tag</a><br>
5.10. <a href="#normalizedtables">Normalized tables</a><br>
5.11. <a href="#multilinemessagesstacktraces">Multi-line messages and stack traces</a><br>6. <a href="#i18n">Internationalization Considerations</a><br>
6.1. <a href="#timezones">Time Zones</a><br>
6.2. <a href="#lang">xml:lang</a><br>7. <a href="#security">Security Considerations</a><br>
7.1. <a href="#zeroconf">Zero configuration</a><br>
7.2. <a href="#sensitiveinfo">Sensitive information</a><br>
7.3. <a href="#transportoptions">Transport options</a><br>
7.3.1. <a href="#sect-ID0EPBAE">Direct messages</a><br>
7.3.2. <a href="#sect-ID0EYBAE">Publish/Subscribe</a><br>8. <a href="#iana">IANA Considerations</a><br>9. <a href="#registrar">XMPP Registrar Considerations</a><br>10. <a href="#schema">XML Schema</a><br>11. <a href="#ack">Acknowledgements</a></p>
<p><a href="#appendices">Appendices</a><br> <a href="#appendix-docinfo">A: Document Information</a><br> <a href="#appendix-authorinfo">B: Author Information</a><br> <a href="#appendix-legal">C: Legal Notices</a><br> <a href="#appendix-xmpp">D: Relation to XMPP</a><br> <a href="#appendix-discuss">E: Discussion Venue</a><br> <a href="#appendix-conformance">F: Requirements Conformance</a><br> <a href="#appendix-notes">G: Notes</a><br> <a href="#appendix-revs">H: Revision History</a></p>
</div>
<hr>
<h2>1.
<a name="intro">Introduction</a></h2>
<p class="" style="">
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 class="" style="">
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 <span class="strong">type='normal'</span>) to the recipient. The recipient in turn, if it understands the payload, can choose to store it in an event log, forward it or
analyze it accordingly.
</p>
<p class="" style="">
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 <a href="https://tools.ietf.org/html/rfc5424">Syslog</a> [<a href="#nt-ID0ELE">1</a>] compliant event information, even though the <a href="https://tools.ietf.org/html/rfc5424">Syslog</a> 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 <a href="https://tools.ietf.org/html/rfc5424">Syslog</a> specification.
</p>
<p class="" style="">
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
<span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a></span> [<a href="#nt-ID0ECF">2</a>] 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 <a href="#transportoptions">Security Considerations</a> section.
</p>
<h2>2.
<a name="glossary">Glossary</a></h2>
<p class="" style="">The following table lists common terms and corresponding descriptions.</p>
<div class="indent">
<dl>
<di>
<dt><strong>Event</strong></dt>
<dd>A piece of information describing an event in time.</dd>
</di>
<di>
<dt><strong>Event ID</strong></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><strong>Event Level</strong></dt>
<dd>Provides an additional level on the previous classification (Minor, Medium, Major).</dd>
</di>
<di>
<dt><strong>Event Type</strong></dt>
<dd>Coarse classification of the event (Debug, Informational, Notice, Warning, Error, Critical, Alert, Emergency).</dd>
</di>
<di>
<dt><strong>Facility</strong></dt>
<dd>What type of device, server, application, etc., is sending the message. </dd>
</di>
<di>
<dt><strong>Message</strong></dt>
<dd>A (human readable) text message describing what has occurred.</dd>
</di>
<di>
<dt><strong>Module</strong></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><strong>Object</strong></dt>
<dd>The object to which the event message refers to, on which the current action is performed.</dd>
</di>
<di>
<dt><strong>Stack Trace</strong></dt>
<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
to define custom tags.
</dd>
</di>
<di>
<dt><strong>Subject</strong></dt>
<dd>The subject causing the event to take place or performing the action (for instance, user, process, etc.)</dd>
</di>
<di>
<dt><strong>Tag</strong></dt>
<dd>A custom tag or parameter attached to an event. Each tag has a name and a value and an optional data type.</dd>
</di>
<di>
<dt><strong>Timestamp</strong></dt>
<dd>When the event occurred.</dd>
</di>
</dl>
</div>
<h2>3.
<a name="usecases">Use Cases</a></h2>
<div class="indent">
<h3>3.1 <a name="simpleevent">Sending a simple event message</a></h3>
<p class="" style="">
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 <span class="strong">timestamp</span> attribute, and the actual messages goes into a child element
named <span class="strong">message</span>. This event will be treated as a <span class="strong">Minor Informational</span> event by the recipient.
</p>
<p class="caption"><a name="example-1"></a>Example 1. Simple event message</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:52:23Z'>
<message>Something happened.</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.2 <a name="multilinemessage">Sending a multi-line event message</a></h3>
<p class="" style="">
The following example shows how to send a multi-line event.
</p>
<p class="caption"><a name="example-2"></a>Example 2. Multi-line event message</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-12T11:47:12Z'>
<message>10 objects deleted:
Object 1
...
Object 10</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.3 <a name="typelevel">Specifying type and level</a></h3>
<p class="" style="">
The following example shows how an event message can be categorized with an event type and level.
</p>
<p class="caption"><a name="example-3"></a>Example 3. Specifying type and level</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:54:55Z' type='Warning' level='Major'>
<message>Low on memory.</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.4 <a name="objectsubject">Specifying object and subject</a></h3>
<p class="" style="">
The following example shows how an event message can be further enhanced by providing object and subject information.
</p>
<p class="caption"><a name="example-4"></a>Example 4. Specifying object and subject</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:58:12Z' type='Informational' level='Major' object='Towel' subject='Arthur Dent'>
<message>Object deleted.</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.5 <a name="eventids">Specifying an event ID</a></h3>
<p class="" style="">
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.
</p>
<p class="caption"><a name="example-5"></a>Example 5. Specifying an event ID</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' id='LoginFailed' timestamp='2013-11-10T16:04:45Z' type='Warning' level='Minor' object='user1' subject='10.0.0.1'>
<message>User attempted to login but provided incorrect password.</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.6 <a name="tags">Tagging events with custom information</a></h3>
<p class="" style="">
The following example shows how to tag an event using custom information in a way that is easy to interpret and process.
</p>
<p class="caption"><a name="example-6"></a>Example 6. Tagging events with custom information</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' xmlns:xs='http://www.w3.org/2001/XMLSchema'
timestamp='2013-11-10T16:07:01Z' type='Informational' level='Minor'>
<message>Current resources.</message>
<tag name='RAM' value='1655709892' type='xs:long'/>
<tag name='CPU' value='75.45' type='xs:double'/>
<tag name='HardDrive' value='163208757248' type='xs:long'/>
</log>
</message>
</pre>
</div>
<span class="strong">Note:</span> Any <span class="strong">tag</span> elements must come after the <span class="strong">message</span> element.
</div>
<div class="indent">
<h3>3.7 <a name="modules">Specifying program module</a></h3>
<p class="" style="">
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.
</p>
<p class="caption"><a name="example-7"></a>Example 7. Specifying program module</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T16:17:56Z' type='Error' level='Major' object='object1' subject='user1' module='application1'>
<message>Something horrible happened.</message>
</log>
</message>
</pre>
</div>
</div>
<div class="indent">
<h3>3.8 <a name="debug">Sending debug information</a></h3>
<p class="" style="">
The following example shows how to send a debug message with a stack trace, module and custom information.
</p>
<p class="caption"><a name="example-8"></a>Example 8. Sending debug information</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' xmlns:xs='http://www.w3.org/2001/XMLSchema'
timestamp='2013-11-10T16:12:25Z' type='Debug' level='Major' module='My new application' stackTrace='file1, line 1, ...'>
<message>Something is rotten in the state of Denmark.</message>
<tag name='a' value='1' type='xs:int'/>
<tag name='b' value='10' type='xs:int'/>
<tag name='s' value='Hello World!' type='xs:string'/>
<stackTrace>File1, Line1, ...
File2, Line2, ...
...</stackTrace>
</log>
</message>
</pre>
</div>
<span class="strong">Note:</span> Any <span class="strong">stackTrace</span> element must come after the <span class="strong">message</span> element and any <span class="strong">tag</span> elements.
</div>
<div class="indent">
<h3>3.9 <a name="multipleevents">Sending multiple events</a></h3>
<p class="" style="">
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>
<p class="caption"><a name="example-9"></a>Example 9. Sending multiple events</p>
<div class="indent">
<pre class="prettyprint">
<message from='[email protected]/device' to='[email protected]' type='normal' xml:lang='en'>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:52:23Z'>
<message>Something happened.</message>
</log>
<log xmlns='urn:xmpp:eventlog' timestamp='2013-11-10T15:54:23Z'>
<message>Something else happened.</message>
</log>
</message>
</pre>
</div>
</div>
<h2>4.
<a name="support">Determining Support</a></h2>
<p class="" style="">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 <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0030.html">Service Discovery</a></span> [<a href="#nt-ID0ECFAC">3</a>] information requests.</p>
<p class="caption"><a name="example-10"></a>Example 10. Service discovery information request</p>
<div class="indent">
<pre class="prettyprint">
<iq type='get'
from='[email protected]/device'
to='[email protected]'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
</pre>
</div>
<p class="caption"><a name="example-11"></a>Example 11. Service discovery information response</p>
<div class="indent">
<pre class="prettyprint">
<iq type='result'
from='[email protected]'
to='[email protected]/device'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:eventlog'/>
...
</query>
</iq>
</pre>
</div>
<p class="" style="">
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 <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0115.html">Entity Capabilities</a></span> [<a href="#nt-ID0EZFAC">4</a>]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
</p>
<h2>5.
<a name="impl">Implementation Notes</a></h2>
<div class="indent">
<h3>5.1 <a name="eventtype">Event Type</a></h3>
<p class="" style="">
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 <span class="strong">Informational</span>.
It is largely based on the severity levels of <a href="https://tools.ietf.org/html/rfc5424">Syslog</a>.
</p>
<div class="indent">
<p class="caption"><a name="table-1"></a>Table 1: Event Types</p>
<table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="">Type</th>
<th colspan="" rowspan="">Description</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">Debug</td>
<td colspan="" rowspan="">Developers can ask applications to send debug messages during development or testing to more easily see what happens in a system.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Informational</td>
<td colspan="" rowspan="">An informational message describing a normal event.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Notice</td>
<td colspan="" rowspan="">Represents a significant condition or change that administrators should be aware of.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Warning</td>
<td colspan="" rowspan="">A warning condition. If not taken into account, the condition could turn into an error.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Error</td>
<td colspan="" rowspan="">An error condition. A condition has been detected that is considered to be an error or a fault.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Critical</td>
<td colspan="" rowspan="">A critical condition. An error so great that it could escalate into something graver if not addressed.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Alert</td>
<td colspan="" rowspan="">An alert condition. Action must be taken immediately.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Emergency</td>
<td colspan="" rowspan="">System is unusable.</td>
</tr>
</table>
</div>
</div>
<div class="indent">
<h3>5.2 <a name="eventlevel">Event Level</a></h3>
<p class="" style="">
Given an Event Type, an event level can provide additional information about the extent or importance of the event (a second dimension).
</p>
<div class="indent">
<p class="caption"><a name="table-2"></a>Table 2: Event Levels</p>
<table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="">Level</th>
<th colspan="" rowspan="">Description</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">Minor</td>
<td colspan="" rowspan="">Minor events, concerning normal operating procedures.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Medium</td>
<td colspan="" rowspan="">Medium events.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Major</td>
<td colspan="" rowspan="">More substantial events or events that are affecting larger parts of the system.</td>
</tr>
</table>
</div>
</div>
<div class="indent">
<h3>5.3 <a name="eventid">Event ID</a></h3>
<p class="" style="">
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 easily extract subsets of events for processing without having to parse message texts (which should be allowed to be localizable).
</p>
<p class="" style="">
<span class="strong">Note:</span> To avoid problems when running applications using different locales, event IDs should never be localized.
</p>
</div>
<div class="indent">
<h3>5.4 <a name="object">Object</a></h3>
<p class="" style="">
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.
</p>
</div>
<div class="indent">
<h3>5.5 <a name="subject">Subject</a></h3>
<p class="" style="">
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 subject by using this attribute.
</p>
</div>
<div class="indent">
<h3>5.6 <a name="facility">Facility</a></h3>
<p class="" style="">
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 <a href="https://tools.ietf.org/html/rfc5424">Syslog</a>, and leaves it open. However, it is left as a special attribute since
it is important in monitoring applications.
</p>
</div>
<div class="indent">
<h3>5.7 <a name="module">Module</a></h3>
<p class="" style="">
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.
</p>
</div>
<div class="indent">
<h3>5.8 <a name="stacktrace">Stack Trace</a></h3>
<p class="" style="">
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.
</p>
</div>
<div class="indent">
<h3>5.9 <a name="tag">Tag</a></h3>
<p class="" style="">
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
<a href="http://xmpp.org/registrar/xdv-datatypes.html">Data Forms Validation Datatypes</a> [<a href="#nt-ID0EAOAC">5</a>] that is maintained by the XMPP Registrar.
</p>
<p class="" style="">
<span class="strong">Note:</span> To avoid problems when running applications using different locales, tag names should never be localized.
</p>
</div>
<div class="indent">
<h3>5.10 <a name="normalizedtables">Normalized tables</a></h3>
<p class="" style="">
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.
</p>
<p class="" style="">
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>
</div>
<div class="indent">
<h3>5.11 <a name="multilinemessagesstacktraces">Multi-line messages and stack traces</a></h3>
<p class="" style="">
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.
</p>
</div>
<h2>6.
<a name="i18n">Internationalization Considerations</a></h2>
<div class="indent">
<h3>6.1 <a name="timezones">Time Zones</a></h3>
<p class="" style="">
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 class="" style="">
<span class="strong">Note:</span> 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 class="" style="">
If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.
</p>
</div>
<div class="indent">
<h3>6.2 <a name="lang">xml:lang</a></h3>
<p class="" style="">
Event messages SHOULD contain an <span class="strong">xml:lang</span> attribute on the message stanza to specify the language
used in message texts, etc. If language information is not available, e.g. if relaying messages are not created by the device itself,
the <span class="strong">xml:lang</span> attribute can be omitted.
</p>
</div>
<h2>7.
<a name="security">Security Considerations</a></h2>
<div class="indent">
<h3>7.1 <a name="zeroconf">Zero configuration</a></h3>
<p class="" style="">
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.
</p>
</div>
<div class="indent">
<h3>7.2 <a name="sensitiveinfo">Sensitive information</a></h3>
<p class="" style="">
<span class="strong">Never</span> log information that should be handled securely or encrypted, such as passwords.
</p>
</div>
<div class="indent">
<h3>7.3 <a name="transportoptions">Transport options</a></h3>
<p class="" style="">
The following subsections lists different transport options together with security considerations for each one.
</p>
<div class="indent">
<h3>7.3.1 <a name="sect-ID0EPBAE">Direct messages</a></h3>
<p class="" style="">
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.
</p>
</div>
<div class="indent">
<h3>7.3.2 <a name="sect-ID0EYBAE">Publish/Subscribe</a></h3>
<p class="" style="">
Event messages could be published using <a href="http://xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a>. Unless there's absolute control
of who can subscribe to the information published in this manner, the information should be considered open and freely available. In such cases extra
care should be taken to not publish information of a sensitive nature, or information that can be mined for information, behavior patterns, trends, etc.,
that can be viewed as being of a sensitive nature. If there's a risk that either absolute control cannot be achieved and information is of a sensitive
nature, this pattern should be avoided.
</p>
</div>
</div>
<h2>8.
<a name="iana">IANA Considerations</a></h2>
<p class="" style="">This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span> [<a href="#nt-ID0EVCAE">6</a>].</p>
<h2>9.
<a name="registrar">XMPP Registrar Considerations</a></h2>
<p class="" style="">
The <a href="#schema">protocol schema</a> needs to be added to the list of <a href="http://xmpp.org/resources/schemas/">XMPP protocol schemas</a>.
</p>
<h2>10.
<a name="schema">XML Schema</a></h2>
<p class="caption">
</p>
<div class="indent">
<pre class="prettyprint">
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:eventlog'
xmlns='urn:xmpp:eventlog'
elementFormDefault='qualified'>
<xs:element name='log'>
<xs:complexType>
<xs:sequence>
<xs:element name='message' type='xs:string' minOccurs='1' maxOccurs='1'/>
<xs:element name='tag' minOccurs='0' maxOccurs='unbounded'>
<xs:complexType>
<xs:attribute name='name' type='xs:string' use='required'/>
<xs:attribute name='value' type='xs:string' use='required'/>
<xs:attribute name='type' type='xs:QName' use='optional' default='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='stackTrace' type='xs:string' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='timestamp' type='xs:dateTime' use='required'/>
<xs:attribute name='id' type='xs:string' use='optional'/>
<xs:attribute name='type' type='EventType' use='optional' default='Informational'/>
<xs:attribute name='level' type='EventLevel' use='optional' default='Minor'/>
<xs:attribute name='object' type='xs:string' use='optional'/>
<xs:attribute name='subject' type='xs:string' use='optional'/>
<xs:attribute name='facility' type='xs:string' use='optional'/>
<xs:attribute name='module' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:simpleType name='EventType'>
<xs:restriction base='xs:string'>
<xs:enumeration value='Debug'/>
<xs:enumeration value='Informational'/>
<xs:enumeration value='Notice'/>
<xs:enumeration value='Warning'/>
<xs:enumeration value='Error'/>
<xs:enumeration value='Critical'/>
<xs:enumeration value='Alert'/>
<xs:enumeration value='Emergency'/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='EventLevel'>
<xs:restriction base='xs:string'>
<xs:enumeration value='Major'/>
<xs:enumeration value='Medium'/>
<xs:enumeration value='Minor'/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</pre>
</div>
<h2>11.
<a name="ack">Acknowledgements</a></h2>
<p class="" style="">
Thanks in alphabetical order to Dave Cridland, Joachim Lindborg, Karin Forsell, Lance Stout, Ludovic Bocquet, Markus Kohlhase, Matthew Wild, Mike Taylor, Philipp Hancke, Robert Kosten,
Steffen Larsen, Teemu Väisänen, Waqas Hussain and Yusuke DOI for all valuable feedback.
</p>
<hr><a name="appendices"></a><h2>Appendices</h2>
<hr><a name="appendix-docinfo"></a><h3>Appendix A: Document Information</h3>
<p class="indent">
Series: <a href="http://xmpp.org/extensions/">XEP</a><br>
Number: 0337<br>
Publisher: <a href="/xsf/">XMPP Standards Foundation</a><br>
Status:
<a href="http://xmpp.org/extensions/xep-0001.html#states-Experimental">Experimental</a><br>
Type:
<a href="http://xmpp.org/extensions/xep-0001.html#types-Standards Track">Standards Track</a><br>
Version: 0.1<br>
Last Updated: 2014-01-08<br>
Approving Body: <a href="http://xmpp.org/council/">XMPP Council</a><br>Dependencies: XMPP Core, XEP-0001<br>
Supersedes: None<br>
Superseded By: None<br>
Short Name: eventlogging<br>
Source Control:
<a class="standardsButton" href="http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0337.xml">HTML</a><br>
This document in other formats:
<a class="standardsButton" href="http://xmpp.org/extensions/xep-0337.xml">XML</a>
<a class="standardsButton" href="http://xmpp.org/extensions/xep-0337.pdf">PDF</a></p>
<hr><a name="appendix-authorinfo"></a><h3>Appendix B: Author Information</h3>
<div class="indent">
<h3>Peter Waher</h3>
<p class="indent">
Email:
<a href="mailto:[email protected]">[email protected]</a><br>
JabberID:
<a href="xmpp:[email protected]">[email protected]</a><br>
URI:
<a href="http://www.linkedin.com/in/peterwaher">http://www.linkedin.com/in/peterwaher</a><br></p>
</div>
<hr><a name="appendix-legal"></a><h3>Appendix C: Legal Notices</h3>
<div class="indent">
<h4>Copyright</h4>This XMPP Extension Protocol is copyright © 1999 - 2013 by the <a href="http://xmpp.org/">XMPP Standards Foundation</a> (XSF).<h4>Permissions</h4>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.<h4>Disclaimer of Warranty</h4><span style="font-weight: bold">## 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. ##</span><h4>Limitation of Liability</h4>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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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.<h4>IPR Conformance</h4>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <<a href="http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/">http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/</a>> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).</div>
<hr><a name="appendix-xmpp"></a><h3>Appendix D: Relation to XMPP</h3>
<p class="indent">The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.</p>
<hr><a name="appendix-discuss"></a><h3>Appendix E: Discussion Venue</h3>
<p class="indent">The primary venue for discussion of XMPP Extension Protocols is the <<a href="http://mail.jabber.org/mailman/listinfo/standards">[email protected]</a>> discussion list.</p>
<p class="indent">Discussion on other xmpp.org discussion lists might also be appropriate; see <<a href="http://xmpp.org/about/discuss.shtml">http://xmpp.org/about/discuss.shtml</a>> for a complete list.</p>
<p class="indent">Errata can be sent to <<a href="mailto:[email protected]">[email protected]</a>>.</p>
<hr><a name="appendix-conformance"></a><h3>Appendix F: Requirements Conformance</h3>
<p class="indent">The following requirements keywords as used in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</p>
<hr><a name="appendix-notes"></a><h3>Appendix G: Notes</h3>
<div class="indent">
<p><a name="nt-ID0ELE">1</a>.
RFC-5424: The Syslog Protocol <<a href="https://tools.ietf.org/html/rfc5424">https://tools.ietf.org/html/rfc5424</a>>
</p>
<p><a name="nt-ID0ECF">2</a>. XEP-0060: Publish-Subscribe <<a href="http://xmpp.org/extensions/xep-0060.html">http://xmpp.org/extensions/xep-0060.html</a>>.</p>
<p><a name="nt-ID0ECFAC">3</a>. XEP-0030: Service Discovery <<a href="http://xmpp.org/extensions/xep-0030.html">http://xmpp.org/extensions/xep-0030.html</a>>.</p>
<p><a name="nt-ID0EZFAC">4</a>. XEP-0115: Entity Capabilities <<a href="http://xmpp.org/extensions/xep-0115.html">http://xmpp.org/extensions/xep-0115.html</a>>.</p>
<p><a name="nt-ID0EAOAC">5</a>.
Data Forms Validation Datatypes <<a href="http://xmpp.org/registrar/xdv-datatypes.html">http://xmpp.org/registrar/xdv-datatypes.html</a>>
</p>
<p><a name="nt-ID0EVCAE">6</a>. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <<a href="http://www.iana.org/">http://www.iana.org/</a>>.</p>
</div>
<hr><a name="appendix-revs"></a><h3>Appendix H: Revision History</h3>
<p>Note: Older versions of this specification might be available at <a href="http://xmpp.org/extensions/attic/">http://xmpp.org/extensions/attic/</a></p>
<div class="indent">
<h4>Version 0.1 (2014-01-08)</h4>
<div class="indent">
<p class="" style="">
Initial published version approved by the XMPP Council.
</p>
(psa)
</div>
<h4>Version 0.0.2 (2013-12-02)</h4>
<div class="indent">
<p class="" style="">Addressed pre-publication feedback from the XMPP Council.</p>
(pw)
</div>
<h4>Version 0.0.1 (2013-11-10)</h4>
<div class="indent">
<p class="" style="">First draft.</p>
(pw)
</div>
</div>
<hr>
<p>END</p>
</body>
</html>