Hi, I believe that we originally put in the "backwards compatibility" wording in syslog-sign so that the mechanism could be used by classic syslog (3164 style) and also in what we were defining as the protocol in that ID (now syslog-protocol). I also think that those thoughts just got migrated into syslog-protocol because they were in syslog-sign. I still like the idea of allowing that in syslog-sign so perhaps syslog-sign should be modified to say "you really should be using syslog-protocol so do it _this_ way. However, if you want this type of authentication applied to what you currently send as syslog messages, then do it _that_ way."
In syslog-protocol, perhaps it would be better to just say "MUST" about the new fields. Rainer makes a good point that we would really like to build syslog-protocol on the vast amount of momentum currently being held by classic syslog. To do that in the least disruptive way, I think we should still use udp/514 and still remain somewhat similar to the classic fields in use. Would it be suitable to state that intention that in the Abstract or Introduction in syslog-protocol? Perhaps it would also be good to restate "be conservitive in what you send, and liberal in what you receive" to note that syslog servers should be capable of receiving both syslog-protocol messages as well as classic style messages. Thanks, Chris On Mon, 26 Jan 2004, Rainer Gerhards wrote: > 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. > > > > > > > > > > > > > > >
