Hi, I agree that a version number would be helpful; it will be even more helpful when the **next** version of a syslog standard is published.
I suggest that you should consider adding two fields to a standardized syslog format: the (IANA-assigned) enterprise ID and a version number. (The IETF should have an enterprise ID, and I know other IETF work has considered 0 to be the IETF enterpriseID, but check with Joyce Reynolds whether 0 should be used for this or not.) This would allow vendors to migrate their existing proprietary versions of syslog to an intermediate standardized message format, without forcing them to go all the way to fully standardized content. Some syslog messages may be encoded in hardware, or in licensed binary software, or in code the vendor cannot economically justify changing all at once, and will be difficult to migrate the content to a fully-standard syslog format. However, the embedded software that creates the final messages for the wire may be able to wrap the content in a standarized message format, improving manageability and interoperability. Applications that read syslog messages may be able to support some vendor formats and not others, and the enterprise ID and the version number provide quick and useful filtering of messages. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Monday, January 26, 2004 12:33 PM > To: Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: syslog-protocol-01 posted & comments > > 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 > > >
