Anton, one more comment:
> > implementation will be out for many years to come. Obviously, > > all real-world syslogds will need to support those older > > clients - or they will not receive market acceptance. > > I think nothing prevents a syslog server implementation from complying > with both RFC 3164 and RFC.new. I think there is indeed a *big* issue. I may be totally missing the obvious, but how can a syslogd - IN A STANDARD WAY - differntiate between legacy syslog and -protocol? Its an honest question. Hoewever, the only answers I have seen to similar issues so far is "look at the headers and guess" - I think this is not good. Maybe we should REQUIRE a specifc structured data element to be present, to say "hey, this is new format" - this could solve it. Is that an idea? A sample for a REQUIRED structured data element: [EMAIL PROTECTED] version="1"] Everything that does not have this structued data element, MUST be considered "old style", everthing that has it MUST be fully compliant with -protocol. A syslogd just implementing -protocol is free to drop all packets that do not have this element. How does this sound? Another approach may be to change the message format, eg. instead of <PRI>...... -protcol may start with [VERSION, FACILITY, SEVERITY].... deliberately breaking compatibility. Comments are highly appreciated. Rainer
