[Standards] Updated XEP: Event Logging over XMPP
Peter.Waher at clayster.com
Tue Nov 12 15:22:42 UTC 2013
Thanks for the input. I'll cut the mail down a bit and answer remaining questions:
>>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.
Similar, but not the same. The main point in the future IoT event XEP is the requesting of certain events, and the recognition of the response, not the actual message itself. But I'll explain more later. Similar to a request/response mechanism (XEP-0323) but based on conditions, and you get multiple responses, once every time a condition is met.
>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 Agree. Couldn't find it now, but I seem to remember previous discussions of implementations where they didn't concern themselves with namespaces. Having different local names too would avoid problems in such implementations. (Are there any such implementations left or do all use strict qualified names to identify elements?)
>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.
Correct. You only have a 0 or 1 relationship to an attribute from an element, which is why I used attributes for those information fields that are required (1) or optional (0 or 1). Tags come in any number (*) so you're forced to add them as child elements.
>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 complex 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.
I agree on this point. I changed the XEP and have put message and stackTrace as child elements instead of attributes. I'll send out a new version.
I've also written an implementation note on my misgivings regarding to indentation, to make sure. (Not that I believe it's a big problem, but you never know.)
>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 just wanted to be able to map the information from Syslog as one example, not necessarily follow the internal structure of messages. Anyway, added the child elements as they make it easier to define multi-line messages.
>> 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.
Ok. I'll add a section about this in the Security Considerations section.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards