Hi, this is a reply both to Andrew's as well as Anton's post.
I have the following scenario on my mind: A company has installed devices speaking both old-style syslog (not necessarily RFC 3164) as well as -protocol. All of their messages should be centralized in a single store. My current approach is to keep -protocol open enough to allow reception of these old-style messages. That is, the syslogd would receive the message and while parsing detect if it is actually the new format or not. If not, it would know these are old style messages (there would definitely be need for some additional relay rules in the raft). I am doing it in this spirit, because my experience tells me if you don't allow this, every vendor will go ahead and create its own version of the (I-have-a-single-daemon-and-do-all-within-it approach). So I am mostly concerned when receiving messages. Anton's comments seem very wisely to address the sender part. There, of course, I would like to a see a fixed (or at least very limited) format, too. Would it be a solution to to specify rules that, when sendinging, there are only MUSTs in regard to the format but there are SHOULDs when receiving? We can also drop the backwards compatibility totally. But then we should be ready to go the full route, that is we should create a new UDP transport mapping and have a port other than 514 assigend. So you would need both a traditional, port 514 receiver for the old stuff and a new port whatever receive for the new stuff. While I think this would technically be the best way to handle it, I am a bit concrend of what this costs us in terms of "ooohhh, this is not syslog, this is a new protocol" missing acceptance by the average user. Still, we would need to define some rules for relays. Rainer > -----Original Message----- > From: Andrew Ross [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 24, 2004 9:33 AM > To: 'Anton Okmianski'; Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: syslog-protocol-01 posted & comments > > > Like Anton, I would like to ensure that RFC.new uses a new, specific > message format, that does not use the RFC3164 timestamp. > > The [] or <> bracketing system with some sort of escaping > will work for > me. > > My expectation is that if a syslog relay/collector receives a RFC3164 > (or any non-RFC.new format) message, that it will modify it > and send it > on (or log it to disk) in the RFC.new format. > > It sounds like we are all on the same wavelength, but saying it in a > different way. > > Cheers > > Andrew > > > > >Anton wrote... > >I would rather leave RFC 3164 as open as it is. But in > RFC.new define > a > >strict format we want new applications follow. So, if somebody says > that > >their syslog client is RFC.new-compliant then it means it fires > messages > >in one precise format we know is desirable. And not, maybe a new > format, > >but maybe also some old one like with old timestamp. > Otherwise, we are > >allowing an implementation to use an old format and claim it is > >RFC.new-compatible. I think it is not desirable. This would require > me, > >for example, saying to our development groups that being > compliant with > >RFC.new is not enough. I would also have to ask for > implementations of > >a specific timestamp format, for example. I'd rather not have to do > >that wherever possible. It creates ambiguity around the RFC. > > > > > >
