Rainer & all: I see your concerns, but I don't think -protocol and -transport have to either both do a complete binary or neither. For one, you can think of them as protocols which operate at different layers of the OSI model.
Keep in mind that we already do "binary" in -protocol because we support entire Unicode. I actually think ultimately it would have been great to separate semantics/schema of -protocol (defined with say with ASN.1) and its encoding (BER, DER, ASCII+Unicode, XML, etc). This would have allowed for binary encoding for high-performance scenarios and XML encoding for those who can't live without it. It would also make it much easier to deal with optional fields or fields that may have multiple values. Trust me, people will re-invent syslog in XML because ASCII formats are "too inflexible" (google for "IBM CBE"). I think the current specification strikes a good balance between binary and ASCII and has a good scope for this iteration. Syslog UDP (SUDP for now) transport adds a very limited function on top of UDP - fragmenting of messages. As we have agreed, it is not even part of -protocol because it is basically part of the transport layer as opposed to application data. There are precedents for application data being in whatever format. So, if we want most of it to be in straight ASCII, ZIP or whatever it is fine. But for the transport layer, TCP/UDP/IP follow their own conventions and they use binary. It is more consistent to just follow them and use binary for syslog UDP transport header. It would be consistent with other transport encapsulation layers of UDP/IP and may even make SUDP applicable in other domains. So, I think the distinction between transport and application data is key here. I can't speak for how eagerly implementors will adopt one format versus the other. I hope a shear use of binary vs ASCII in the simple transport header will no change that. In fact, I think it could make it easier to program when you have a fixed-size header. In SUDP case, it could be one of two fixed size headers: 1 or 12 bytes. Still better than a variable field size for every field. Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Friday, April 23, 2004 8:11 AM > To: [EMAIL PROTECTED] > Subject: binary fields in syslog > > > 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.htm> l). 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 > >
