An interesting comment. Have you been following the prior discussion, over the last six months or so, that has led us to this point? I'll try to sum it up. The current practice of logging uncontrolled free-format strings works to a point, and another design project on this list (SELP) is trying to tweak RFC 3164 to the least extent possible to correct its gross defects. But there's one big downside to the current approach: it makes no attempt to (a) precisely and unambiguously preserve as much information as possible from the logging source, and (b) attempt to offer developers a rich and comprehensive lexicon for classifying log events. These two defects are important and costly ways that current syslog, mostly in the API, is inadequate; it's not capturing all the knowlege that's available at the point of logging, and not all of what it doesn't capture can be reconstructed robustly. It's lossy at the logging API as well as the transport. After some discussion we came up with a convention for a tagged transport format (suitable for carrying in the MSG of an RFC 3164 syslog, or SELP, or RFC 3195 syslog-in-BEEP, or ...); and we're working out a concept for how a global lexicon of known tags and perhaps in some cases values can be maintained over time, as it will certainly have to grow. There are still occasional rumbles of "tagged -vs- XML", from the fragment you quoted perhaps that's not completely settled, but I think there may be a majority of the long-term participants on this thread advocating tagged in preference to XML, mostly on the grounds that it's easier to specify a simple format, barely adequate to express the semantics that we require, than it is to specify exactly _what_ subset of XML is to be used --- and we do _Not_ want people using full-powered XML parsers to grovel logged data, that's a certain road to security problems. Don't provide strangers easy ways to feed powerful parsers. -Bennett
This archive was generated by hypermail 2b30 : Tue Jan 14 2003 - 08:20:25 PST