Anton, actually, I am not convinced. But that's only my opinion. I would *really* appreciate any more feedback from the group. I see that you have very valid reasoning, but, again, I am a bit in fear what this will cause in regard to momentum.
Anyhow, that'll be my last message before we get more comments from others ;) Rainer > -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > Sent: Friday, April 23, 2004 5:31 PM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: binary fields in syslog > > 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 > > > > > >
