Hi WG, this is not only in reply to Anton's posts, but a general thing. So I thought I start with a new subject.
Anton suggest the use of a binary header in -transport (eg http://www.syslog.cc/ietf/autoarc/msg01197.html). Previously, all numbers in syslog were expressed in ASCII digits terminated by spaces. I can understand Anton's efficiency concerns. However, if we go for a binary header in -transport, we could/should also reconsider that issue in -protocol and all other syslog IDs/RFCs. Not just to keep them consistent, but also to be as efficient as possible. HOWEVER, I do NOT like the idea of binary numbers. I think there is good reasoning that many modern protocols have gone away from binary and sacrified some efficiency to do things somewhat easier. The plus in ascii digits is: - esay human interaction - not just reading but also (telnet) crafting messages (I couldn't envision troubleshooting SMTP configs without the ability to telnet SMTP commands) - it's instantly interoperable - no need for network bytes ordering - I think it reduces implementation errors Ffinally, in the context of syslog, we are already very far from RFC 3164. I am already very concerned if our changes will be accepted by the implementor community. If we now move even one more step ahead and create a fully binary protocol... I fear we would finally loose them. And to gain some more efficiency, we could also BER-encode the structured data elements ;) So I short: I *strongly, strongly* advocate to keep things in ASCII. But if we *really* go ahead and define transport to use binary data (for efficiency), we should also go ahead and change -protocol to be binary, too. Rainer
