Anton & all: comments to just to those things that I think I need to comment on - the others are snipped out (basically agreement from my side).
> > > > - 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) > > This is analogy is not quite kosher IMO. SMTP uses TCP/IP and you > don't get to troubleshoot TCP segmentation, flow control or IP > fragmentation when simulating SMTP via Telnet. I guess you are > implying that syslog transport is part of the application layer. I > think, in the present form, it is not because it has pretty much > nothing in the protocol that is syslog-specific. It is just a generic > extension to the UDP protocol to support fragmentation. I think the analogy is right in this case. Because even though I do not get all these things with telnet/netcat, I can use it for troubleshooting. I can't use it for troubleshooting the UDP layer, that's right - but that's not the thing I was asking for. I think whenever you add something binary on top of UDP (or IP), you can not use all those tools that work on generic packets, but you need a specialised tool - which probably is much where the network operator's position that David quoted comes from... .... > I also think it is a slippery slope toward somebody asking that these > transport fields be encoded in XML because it makes it even more > easier to troubleshoot the protocol when you have field descriptors > right there... I think, this, too, is a separate issue. My point is that I would like to use generic tools, not special ones. If we use ASCII on top of UDP/TCP I can use generic tools. If we go binary, I can't. The ability to use generic tools does not necessarily mean it needs to be overly simple... at least this is my position. > I think one needs to read a spec if he is > troubleshooting the protocol anyway & use a tool like Ethereal. yes, ethereal is among them. But that's a "watch-only" thing. You also need to use tools to craft packages, and to the best of my (limited;)) knowledge this becomes hard if you go binary. I mean things that you can find right out of the box on most systems... Also please let me re-iterate my concerns about implementor adoption of our work. We are already far away from traditional syslog. If we now even go binary, I think we will loose a lot of momentum. > Anyway, I will proceed with WG consensus. Please voice your opinions > or preferences as I'd like to publish the next draft soon. My choice is definitely towards an USASCII header. Rainer
