[Standards] Updated XEP: Event Logging over XMPP

Dave Cridland dave at cridland.net
Tue Nov 12 13:58:01 UTC 2013


On Tue, Nov 12, 2013 at 1:33 PM, Peter Waher <Peter.Waher at clayster.com>wrote:

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

That could be an event of the same form, of course. RFC 5424 certainly
seems to hint at fully structured events.

But in any case, the difficulty with having the term of art "event"
overloaded doesn't really go away; at least in XML we have namespaces to
handle this.


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

It's an argument for using "event".


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

I'm not entirely sure it's the Council's job to make that kind of 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)
>
>
>

But you have them for your "tags", which appear to relate closely to
structured parameters from RFC 5424.


>   >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 think it makes little difference, except that you can have line-endings
in logging messages, and the rules for escaping text nodes are a little
easier than those for attribute values.

One of the reasons I was thinking along these lines is because RFC 5424
appears to be structured in the same manner.

Now, if you assume we're *not* going to attempt to map to or from RFC 5424,
then the situation changes, rather.


>   >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> }
>
> ></event>
>
>
>
> Not sure what to comment.
>
>
>

This space left intentionally blank? ;-)


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

I'd like to sketch out possible transports, because otherwise we'll miss
Security Considerations.

You're quite right in that events are very often sensitive, either
individually or in aggregate.

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


More information about the Standards mailing list