Hi, [speaking as co-chair]
I believe it is inaccurate to say there has been a WG decision to maximize backwards compatibility. The charter says "The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard." There is a big difference between "maximizing for backwards compatibility" and "considering the ease of migration between and the co-existence of existing versions and the standard." This difference was discussed during the charter discussions. We need to balance backwards compatibility with improved interoperability and good technical design. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -----Original Message----- > From: Carson Gaspar [mailto:[EMAIL PROTECTED] > Sent: Friday, August 18, 2006 4:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Legitimate \n or byte-counting > > --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick > <[EMAIL PROTECTED]> wrote: > > > If we use LF-escaping in syslog messages, what's going to > happen if a > > legitimate "\n" is sent by a sender? An example would be: > > > > <PRI>... BOM The offending characters are \n > > > > Will a receiver convert that into LF? If that's the case > then we should > > not be using LF-escaping. > > I raised the same issue. The answer is the receiver will examine the > protocol version and will not un-escape unless the sender is > a new-style > sender. I'm still not convinced that the installed base of TCP syslog > deployments is large enough to care about, but, given the decision to > maximize backwards comparability, this is "good enough" to make > implementation possible. > > -- > Carson > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
