Rainer: Sorry, but I am still not getting backwards compatibility business. Please help me understand it.
Clients which fire messages in RFC.new format are always going to be compatible with RFC 3164 servers regardless of what we put into RFC.new. This is because RFC 3164 allows anything. The way we have the draft now, any RFC 3164 server can accept/relay RFC 3164 or RFC.new messages. This is not an issue. We get this backwards compatibility "for free". Right? Now, will clients which fire messages in *any* RFC 3164 format be compatible with syslog server which implements *only* RFC.new? I hope note because it would defeat the purpose of a new RFC. I think what you spec'ed is at best only partially compatible -- only if they follow some selected recommendations of RFC 3164 which are compatible with RFC.new. Right? > Now to backwards compatibility: Of course, we create a new > standard for new syslog implementation. However, I am *very* > sure that existing RFC 3164 compliant and NON-compliant > 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. And whatever else they want to comply with. None of the RFCs prevent an implementation from processing messages in any other format, right? But our job is to define a precise new format which will be useful to new generations of applications. We are not saying that RFC.new obsoletes RFC 3164, right? 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. Note: if we only support the new timestamp RFC.new messages will *still* be RFC 3164 compatible. So, I don't quite grasp the issue here. Thanks, Anton.
