[Standards] Updated XEP: Event Logging over XMPP

Peter Waher Peter.Waher at clayster.com
Tue Nov 12 13:33:02 UTC 2013

Hello Dave

Thanks for your input. I'll try to respond as best I can:

>FWIW, I have a considerable preference for "event" over "log". A log is a permanent record of events, and you'll note that the literature on logging refers to events...

Yes, the noun log is a log of events. However, log is also a verb, to log something (in a log book for instance). This is how I saw it. My first version used event, for the reason you mentioned. However, Steffens argument that there are so many kinds of "events" made me think twice. And there will be yet another type of event not yet sent to the XSF relating to IoT events (i.e. "tell me when the temperature reaches 20 degrees Celcius so I can ..."  (turn off heater for instance)).

I'm still open to what name we use. I'm fine with log (and event). I'd let the council decide.

> ...In fact, the protoXEP uses that term of art throughout.

Not sure what you mean by this. Is it a question or something I should correct? Or an argument for what you wrote previously?

>Second, I think the "message" attribute should be a child element, with the message as content.

Can change that if it is the council's decision.

It has one advantage, but also one weakness. The advantage obviously is that it is easier to write. The weakness is that indentation might be a problem if you use indentation in your examples for multi-line messages. Attributes are clearer in this regard since you're forced to think about it. I also wanted to drop subelements (see explanation below)

>I think what's needed overall is to map RFC 5424 into XML, and allow extension in roughly the same way that we extend stanza and stream errors. So what you'd get would be the RFC 5424 HEADER construct as a containing event element, and it would contain detail as either a <structured/> element with a sd-id attribute, or a <message/> element.

I wanted to avoid sub-elements at all to allow for very simple messages to be sent. The point was to allow for both simple messages (almost as simple as simple text messages) but still allow for more complexed logging, type Syslog. I see no value in structuring information into sub-elements by itself. It doesn't make it easier to write and it doesn't make it easier to parse. And it does not provide additional information.

>I'd personally drop in facility and severity into the event element itself, because virtually everything uses those instead of PRI, but still.
>The result looks roughly like:
><event lots-of-attributes>
>  { <message>A message here</message> | <structured sd-id='horrible-syntax at 12345'><param name='foo'>Value</param></structured> }

Not sure what to comment.

> As far as transport, I really think that any logging source ought to expose itself as XEP-0060, but I could be wrong there.

Yes, I know some would like to use pubsub. However, the extension is not limited in this regard. Many would think events are or should be considered sensitive information and therefore not published. They would use directed messages to an event sink. Others might disagree, and they could publish the events using pubsub. It must be an implementation issue I believe.

Do you think it is necessary to explicitly write an explanation about this into the XEP? If yes, including examples, or a simple textual description as the one above would be sufficient?

Best regards,
Peter Waher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131112/7972ce67/attachment.html>

More information about the Standards mailing list