> Darren, .. > So why this gap between 3164 and practice? I have come > to the conclusion that after Eric invented it, other folks have redone > his work on other platforms (e.g. Linux, Windows and of course embedded > devices). While all of these implementors had Eric's ideas on their > mind, there was no spec to follow. Thus, each one introduced subtle > differences and finally even BSD syslogd was modified in subtle ways. At > the time 3164 was defined, nobody went to the lab and verified the > results. Nor did I when I started with syslog-protocol. We all were so > convinced that when Eric agreed to the document, it must be right. I > think we do not need to put finger at anyone. ..
I agree with the summary here. > In general, I agree. But I think we should support the currently > existing use cases for syslog. After all, was this effort not put on > hold because it was said it is not backwards-compatible enough? Indeed. But I think there were (or are) protocol subtlties that many people are unaware of. Maybe in your testing of syslog messages you should include sending a message that is 255 characters long 0x1 - 0xff and see what comes out the other end. I'd also recommend that you include Solaris (preferably Solaris 10) in your test suite if you can't include any of HP-UX or AIX. It's probably the most common commercial Unix and people who deploy it are loathe to replace system components with open source bits. Solaris 10 for x86 is a free download. > > > MSG-size-in-octets would be the size of the MSG part (just that!) in > > > octets. Counting just the MSG part is sufficient, as the rest of the > > > message consists of fields properly delimited. The size is > > probably most > > > useful for binary data. > > > > What happens if the message is truncated? > > Good question. I'd say the size would need to be adjusted. What happens if/when the SD data is truncated and either the MSG size is lost or truncated half way through ? I believe there is very little added value of having the message size as part of SD data - or at least not enough to warrant it being treated as a mandatory/required field to include. > > What value is the message size really providing here? > > If we have a natural EOR marker, LF, what do we need the size for? > > We do NOT have a EOR marker. As of the current draft, LF is just a > regular character like any other. We explicitely wanted the capability > to surface, now we have it. I even think its not bad to have it. I do > NOT like the idea to re-iterate that long discussion of whether or not > full UTF-8 should be supported. Please review the mailing list archive > for that. Allowing LF inside a native message is bad, now that I think of it. Supporting UTF-8 doesn't impact what we use as an EOR marker unless we are going to say that the wire format must not be changed from the message supplied by the application. If we're going to be backwards compatible with the use of ^ (and I think we should and continue to use this) then this already points to the on-wire content of the message being different to what is supplied by an application. I can't see any reason why the on-wire format of the message needs to be the same as that supplied by the application. It's not like we use tcpdump or ethereal to do our loging. Darren _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
