On Wed, 2006-07-05 at 11:32 +0200, Balazs Scheidler wrote: > On Tue, 2006-07-04 at 05:27 +1000, Darren Reed wrote: > RFC3195bis is a nice idea, even though I previously disliked that > protocol myself. I'll have to reread that RFC to form my opinion.
I have now refreshed my memories on RFC3195, and my technical opinion is as follows: beep in general: - I like its extensibility and multiple channels, and its support for optional authentication/encryption - I don't like its complexity as we have to think with embedded devices in mind - depends on a whole lot of things, and as I see generating the XML constructs should use a real DOM implementation, as constructing XML with sprintf is asking for trouble (ie: escaping) syslog/raw profile: - this profile does not offer anything more than simple syslog over TCP as currently implemented in syslog-ng and other products, it has significant overhead though: - bandwidth wise: about 30 octets per message, - code wise: the beep framework (beep itself, xml, character sets, entities etc), this can be simplified significantly by supporting a single channel only, always using utf8 and hand-crafting XML with sprintf/parsing it with sax/handmade parser - this profile does not solve record termination, where the latest consensus was to be completely transparent for any unicode character, in syslog/raw CRLF line termination is used when multiple messages are included in a single BEEP frame. - the profile permits a maximum of 1024 bytes per message syslog/cooked profile: - I like the fact that every hop in the message path is properly identified, and proper identification of senders can be performed, - I like that application layer ACKs are present, however I think that it is too verbose (about 30-35 bytes to acknowledge a single message, about 35-40 to nack it) - I don't like that the new format still uses BSD timestamp, no year and no timezone information So as I see, there is absolutely no point in implementing syslog/raw, using the existing protocols is enough for legacy support and implementing syslog/raw is not any easier than using syslog/cooked. And it has issues with record termination and maximum message length. syslog/cooked could be updated with the latest header changes in syslog-transport-udp and with some adjustments it could provide a nice platform for new protocol features in the long run. What this boils down, is that I could support RFC3195bis, especially if we decide that we are bothered by the IPR claim of Huawei. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
