[Standards] eventlogging xeps

Peter Waher Peter.Waher at clayster.com
Tue Dec 10 16:30:23 UTC 2013


Hello Waqas



Thanks for your input. I'll try to respond to your concerns one at a time:



Something which I don't think has been discussed: Encoding. I'm assuming syslog-to-xmpp bridging is something you wish to enable.

Syslog does recommend UTF-8, but doesn't require it. Data can be non-UTF-8. Also, syslog messages can be truncated by bytes, which can lead to invalid UTF-8 at the end of a message (the spec specifically points this out). And lastly, syslog messages may contain a byte-order-mark (BOM) at the start of messages to specify encoding.

Also, XML supports a subset of UTF-8, not all UTF-8 characters are allowed.



What we probably want is some form of escaping to be specified in the spec. Perhaps as simple as: replace \ with \\ and replace any invalid XML bytes with \XX, XX being the byte in hex. BOMs should be removed if available, and data should be converted to UTF-8 if possible.



The objective is not to create a binary compatible mapping, but a conceptual mapping. There's no need to encode BOMs, as the reason for using BOMs is to be able to find out the encoding from a binary file. Text strings in XML are already encoded using the encoding of the stream (UTF-8). If the text message contains characters that are not valid in XML, normal ampersand encoding is sufficient (&...;, like <, > or &x....;)



One thing which looks awkward to me are the 'type' attributes in the 'tag' element. What's a use-case where specifying the data-type would help the receiver (particularly when this would generally be the same in every log message sent by the entity)?



The reason would be for monitoring applications, that listen to the event stream, to be able to perform calculations or comparisons. For instance, consider an application monitoring available memory on a device's flash drive. It does this by listening perhaps to regular events being sent by the devices that report status. In these status events there might be a tag for free memory ("freeMemory") of type xs:nonNegativeInteger, for example. So the monitoring application might have a condition listening for these types of events (using say event ID to identify the particular events) and performing the comparison freeMemory<200000 or freeMemory<"200000", for example. This comparison would return false when comparing against "1000000" since it knows it has to use an integer comparison operator, and not a string comparison operator, if it knew the data type was encoded as such.



And while you are using 'xs:*', the 'xs' namespace isn't defined in the XML stream the stanza is in.



Correct. My mistake. Updated the XEP to include the xs prefix definition and the xml schema namespace whenever used in examples.



Best regards,

Peter Waher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131210/a16c534d/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131210/a16c534d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eventlogging.xml
Type: application/xml
Size: 30013 bytes
Desc: eventlogging.xml
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131210/a16c534d/attachment.xml>


More information about the Standards mailing list