On Tue, 2006-08-15 at 13:50 -0700, Carson Gaspar wrote: > I've been mostly lurking lately, but I would like to re-iterate my support > for byte counting. It's the Right Thing To Do, and theoretical "backwards > compatibility" with existing non-standard non-widely-deployed syslog over > TCP solutions isn't a good enough reason to put bad ideas in the standard.
Then why on earth did the BEEP based syslog/RAW use LF as line terminator? Quoting RFC3195: If multiple syslog messages are included in a single ANS reply, each is separated from the preceding with a CRLF. There is no ending delimiter, but each syslog event message body length MUST be 1024 bytes or less, excluding BEEP framing overhead. Note that there MUST NOT be a CRLF between the text of the final syslog event message and the "END" marking the trailer of the BEEP frame. As it currently stands: * nonstandard, but widely deployed syslog over TCP use LF * nonstandard, less widely deployed syslog-over-TCP-over-SSL use LF * standard, even less widely deployed syslog/RAW uses CRLF * semi-standard, UDP based syslog uses UDP packet framing for message termination Syslog-ng has supported TCP transport since its first release in 1998, a number of devices interoperate with it. Whatever the decision of the working group, syslog-ng will need to support this legacy TCP mode of operation for backward compatibility. And as there is little incentive for a user to change to the byte-counted form, I think the legacy mode will still be more widely used for a couple of years to come. Of course syslog-ng might not be the most widely deployed syslog implementation, but I'm sure it is in the top three. Some numbers using google search, which I know is not really representative: sysklogd 607000 (default on Linux, no TCP support) syslog-ng 593000 kiwi syslog 321000 msyslog 33400 sdsc syslog 21900 rsyslog 21500 In my opinion we either design something that is really sexy (application layer acknowledgements, authentication, compression, something that BEEP based syslog provides but which has other problems) or we should be as compatible with existing installations as possible. In my opinion the goal here is that the user will not need to change its configuration file, or will not need a separate port on her firewalls, a simple software upgrade on either receiver/sender and be done with it. The current TCP based protocol _is_ implemented in closed-box devices where replacing the sender software component is not possible or feasible, if the new feature is incompatible, it will be difficult to convince users to change, unless some real value is also added, other than "byte-counted" form is cleaner. I tend to agree that byte-counting is cleaner, I just don't see the advantate in the current state of affairs. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
