Re: [Standards] eventlogging xeps
Yes, it is better now. -Teemu 2013/12/10 Peter Waher peter.wa...@clayster.com: Hello Teemu Thanks for the feedback. The description in §7.3.2 was perhaps a bit minimalistic. I extended it as follows: Event messages could be published using Publish-Subscribe. 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. Ok? Best regards, Peter Waher -Original Message- From: Teemu Väisänen [mailto:uol...@gmail.com] Sent: den 10 december 2013 14:37 To: XMPP Standards; Peter Waher Subject: Re: [Standards] eventlogging xeps Hi Peter. Section 7.3.2 Publish/Subscribe describes: Event messages could be published using Publish-Subscribe. But, even more care should be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided. If information is sensitive, the information should not be logged, as said in 7.2. Do you mean that if sensitive information is still sent using pubsub, there are more actors (pubsub server, subscribers) that might log and/or leak the sensitive information and because of that the pubsub pattern should be avoided? Would it be wise to move the second line But, even more care should be taken to log only information that can be published openly., e.g., to section 7.2. because it relates also to other cases than pubsub? Could the last sentence be something more like: If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided in systems that contain any not trusted or any uncontrolled actors. That is because we could have a setup where we have a trusted pubsub server and we log (also) sensitive information in several trusted subscribers/loggers. BR, Teemu - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6904 - Release Date: 12/09/13
Re: [Standards] eventlogging xeps
Hi Peter. Section 7.3.2 Publish/Subscribe describes: Event messages could be published using Publish-Subscribe. But, even more care should be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided. If information is sensitive, the information should not be logged, as said in 7.2. Do you mean that if sensitive information is still sent using pubsub, there are more actors (pubsub server, subscribers) that might log and/or leak the sensitive information and because of that the pubsub pattern should be avoided? Would it be wise to move the second line But, even more care should be taken to log only information that can be published openly., e.g., to section 7.2. because it relates also to other cases than pubsub? Could the last sentence be something more like: If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided in systems that contain any not trusted or any uncontrolled actors. That is because we could have a setup where we have a trusted pubsub server and we log (also) sensitive information in several trusted subscribers/loggers. BR, Teemu
Re: [Standards] eventlogging xeps
Hello Teemu Thanks for the feedback. The description in §7.3.2 was perhaps a bit minimalistic. I extended it as follows: Event messages could be published using Publish-Subscribe. 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. Ok? Best regards, Peter Waher -Original Message- From: Teemu Väisänen [mailto:uol...@gmail.com] Sent: den 10 december 2013 14:37 To: XMPP Standards; Peter Waher Subject: Re: [Standards] eventlogging xeps Hi Peter. Section 7.3.2 Publish/Subscribe describes: Event messages could be published using Publish-Subscribe. But, even more care should be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided. If information is sensitive, the information should not be logged, as said in 7.2. Do you mean that if sensitive information is still sent using pubsub, there are more actors (pubsub server, subscribers) that might log and/or leak the sensitive information and because of that the pubsub pattern should be avoided? Would it be wise to move the second line But, even more care should be taken to log only information that can be published openly., e.g., to section 7.2. because it relates also to other cases than pubsub? Could the last sentence be something more like: If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided in systems that contain any not trusted or any uncontrolled actors. That is because we could have a setup where we have a trusted pubsub server and we log (also) sensitive information in several trusted subscribers/loggers. BR, Teemu - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6904 - Release Date: 12/09/13
Re: [Standards] eventlogging xeps
On Mon, Dec 2, 2013 at 9:58 AM, Peter Waher peter.wa...@clayster.com wrote: Hello Philipp Thanks for your input. I've updated the according to your comments, and attach a new version. Best regards, Peter Waher Hey Peter, 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. 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)? And while you are using 'xs:*', the 'xs' namespace isn't defined in the XML stream the stanza is in. -- Waqas Hussain
Re: [Standards] eventlogging xeps
Hi Peter, This is looking really good! Minor things I noticed: - The timestamp attribute. We’ve been using ‘stamp’ as the name for that type of attribute. - The type and level attribute values are currently title cased, but I personally prefer lowercase values since that is what is commonly used. It looks like those were made to match directly with syslog? There are several places where strict element ordering is mandated. Any particular reason why? -Lance signature.asc Description: Message signed with OpenPGP using GPGMail
