Hi Tom, [speaking as a contributor]
Rainer asserted that using LF would not break existing implementations. It does not appear to me that we have reached consensus that this assertion is true. I personally have concerns because this WG has already found that many syslog implementations are not compatible, especially on the point of having reserved/escaped control characters for special use. I asked if Rainer could provide any empirical support for his assertion, or whether his assertion was theoretical. I have not asserted that a message containing an octet count would work with existing implementations; only syslog implementations that were updated to support the not-yet-defined <syslog/tls> standard would use octet counting. Legacy messages without an octet-count would continue to be sent to the legacy syslog port, presumably one by one or delineated using whatever mechanism the legacy implementation currently supports. As I see it, a syslog/tls implementation would prepend an octet-count field to each syslog message, concatenate the messages into a stream, and send the concatenated messages to the new <syslog/tls> port. An implementation that supports the syslog/tls standard would strip off the prepending octet-count and extract each counted syslog message from the stream. Each extracted message could then be processed using the exact same parser code as would be used for messages received at the legacy syslog port. Using an octet-count encapsulation technique like this means the existing syslog message is not touched in any way, and the presence of an octet-counted stream delivered to a special port expecting the octet-counted stream, cannot interfere with any existing assumptions about the message format or content. Note that the syslog messages encapsulated by the octet-count might be able to be of any syslog format. The legacy parser implementation (whichever of the many incompatible variations) would not be changed. If the ability to carry different formats of syslog messages is desired, an additional field should probably be prepended to each syslog message in the stream that identified which syslog parser should be used to parse it. I am not a supporter of this approach because I would rather see implementations move to the syslog-protocol standard, but for those who value backwards compatibility above all else, this might be an interesting property. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: tom.petch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 1:08 PM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] byte-counting vs special character > > ----- Original Message ----- > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Rainer Gerhards'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, August 15, 2006 7:24 PM > Subject: [Syslog] byte-counting vs special character > > > > Hi Rainer, > ><snip>> > > [speaking as contributor] > > I like the argument that the LF solution will not break existing > > implementations, but I would like to know this is actually > true. Have > > you actually tested this against multiple implementations, > or is it a > > theoretical argument? > > > Turning the argument around, how many implementations have > you got and have > tested for interoperability that use byte counting for syslog? > > As Rainer's posts and earlier work as documented on his web > site show, there is > an awful lot of syslog out there, more pre-existing, interoperable > implementation than in any other activity of the IETF I have > been involved with. > For me, this overcomes any technical, architectural considerations of > 'betterness' and says we must go with our best understanding > of the existing > marketplace (I thought differently when I started:-( > > Other participants on this list may only represent a little > of the implemented > code but it is still an awful lot of pre-existing implementation. > > Tom Petch > > > > > I know you have tested a number of other proposed ways of > doing things > > against multiple implementations to try to verify backwards > > compatibility. Have you actually tested multiple existing > > implementations with the LF and found that they do continue to work > > without significant problems? Can you tell the WG which > ones you have > > tested? Are there implementations that break when using > this solution? > > > > > > dbh > > > >/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
