Rainer: I am really struggling with that restriction not to standardize syslog storage in IETF. It diminishes the value of the syslog protocol as people can't write a standard syslog parser.
It would be nice if we could find another standards body which could be used to address that aspect. I assume log analysis mailing list is not affiliated with a standards body, or is it? I wonder if there is good precedent out there of two standards bodies working in tandem like this. Maybe W3C? Somebody suggested to me an idea that maybe a bit wild, but could address this. A protocol for syslog server to return messages it has stored. It could be UDP-based. How much less efficient would that be than reading a file? I don't think the difference will be huge as I/O will likely be the bigger bottleneck anyway. Essentially, the messages could be returned using the same -protocol & -transport and we just need to add some request/response semantics. This does sound pretty wild, but desperate times call for desperate measures :) and I thought I would just pass it along. Anton. > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 10, 2004 12:15 PM > To: Andrew Ross; Harrington, David; Anton Okmianski; > [EMAIL PROTECTED] > Subject: RE: -international: trailer > > > Hi All, > > I am a bit sad that I use Andrew's message to say this... but > Andrew has just made an important point that enlightens me on > David's thought that those CLRs (crappy little rules [I like > this term]) really cause trouble. So Andrew please don't take > my objection personally, I see your reasoning behind it... > > ... but this is an excellent sample on how granting one > exception (the 0x00 case) leads to calls for further > exceptions (0x0a in this case). I have to admit I didn't > think well enough about this. > > Also, I was technically incorrect in insisting on 0x00 to be > too hard for C. Actually, I worked out a surprisingly easy, > obvious and well-known escaping mechanism to handle 0x00 once > the message is received. It looks like I was just too > narrow-minded to think with an open enough mind to solve it. > Thanks to all who kept pushing me :) > > But, honestly, even if I would not see an easy solution for > the C case, I think we should follow David's advise and avoid > any such rules (like the 0x00 exception). In the long term, > they cause more trouble in the long term than the solve initially. > > So I, too, now vote that we must support any valid UTF-8 > sequence in the MSG part, which includes 0x00. If nobody > objects, I will change -protocol to specify this. If you have > objections, I would appreciate if you could reply relatively > quickly, as I try to get -03 out before Seoul. > > Now let me come to the C implementation and other things, > like syslog storage format. As we have discussed on this > list, these things are - at least at first look - not > relevant to IETF work. This is because they simply don't talk > about on-the-wire protocols. And only this is scope of the > IETF. Anyhow, it would definitely be a positive undertaking > to reach concensus among implementors how those things should > be addressed. To have a "least common denominator approach" > that customers could expect to be in syslog products they > purchase/use. Even for the implementors among us, such an > approach would simplify things when it comes to the parsing > and analysis stage. > > I have talked to Chris as well as Tina Bird, who is the > moderator of the loganalysis mailing list > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We > have agreed that we can move discussion for > non-IETF topics over to loganalysis. The big plus in this is > that there are also many, many administrators on the list, so > we will most probably get a lot of feedback from the end user > camp, too. I think this is extremely valuable. > > I plan, however, to focus just some few days on -protocol and > not directly start this other discussion. I think this serves > our deadlines (Seoul meeting) better than doing too much in > parallel. After that, I plan to post an initial message for > those topics on the loganalysis list. If Chris permits, I > would cross-post these message here to the WG list (together > with my whish to only reply to loganalysis;)). > > I hope this is a good proposal, one that will allow us to > make syslog even more interoperable than it is today. > > Rainer > > > -----Original Message----- > > From: Andrew Ross [mailto:[EMAIL PROTECTED] > > Sent: Sunday, February 08, 2004 12:52 AM > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski'; > > [EMAIL PROTECTED] > > Subject: RE: -international: trailer > > > > > > It is not just the 0x00 that we have to worry about. For > TCP transport > > mappings, we need to have a stream delimiter. Currently it is > > generally agreed that it is LF (0x0A). If we don't escape that > > character, we will > > have to resort to a byte length field. Please don't make me > > have to drag > > out my old Syslog over TCP proposal :-) > > > > Cheers > > > > Andrew > > > > > > >
