Hi Rainer, For achieving implementation standards, you could write an informational document called an implementor's argeement, as part of this WG, assuming you can get approval of the chairs and ADs. I would definitley recommend it should only be done by the WG AFTER the work we are supposed to do gets done.
Of course, you could also just publish an informational document without going through the WG. I'm not sure I want to monitor the loganalysis discussion on this list; anybody that wants to follow it can go to the loganalysis list. dbh > -----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/loganalysis). 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 > > > > > > >
