Rainer & all: Let me comment on something...
> > > - 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. > > > - it's instantly interoperable - no need for network > bytes ordering It is a small issue, agree. But so many IETF protocols use network byte ordering (including TCP/UDP/IP) that it is pretty much a defacto standard. > > > - I think it reduces implementation errors Maybe. But maybe there are additional errors in code that looks for ASCII field delimiters, creates temporary strings, checks for valid characters and performs conversion to system types with bounds checking. Either way the code is simple IMO. Data compactness and performance are not my primary concerns here. Rather consistency with other protocols on the same layer and a minimalist approach. Here is an example of how ASCII transport header could look if we go that way: TransportHeaderVersion [space] MultiPartFalg [space] MessageID [space] TotalLength [space] Offset [space] Example of transport headers of two segments: "1 1 12990 1024 0 " "1 1 12990 1024 512 " The single part message header could be: "1 0 0 0 0 " Or, with special rules, just: "1 0 " If people insist on this approach, I can go in that direction and define limits for all of the fields. But IMO this would make for a somewhat strange-looking transport encapsulation and probably reduce applicability of this protocol to syslog. 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 one needs to read a spec if he is troubleshooting the protocol anyway & use a tool like Ethereal. Anyway, I will proceed with WG consensus. Please voice your opinions or preferences as I'd like to publish the next draft soon. Thanks, Anton.
