> Why limit to macros? > > I've seen loads of open source projects that include > implementations of sometimes-missing routines, like e.g. > various printf varients (snprintf, vfprintf, ...). Make one > of the first implementations of the new logging API be a > simple C version that backends onto syslog(3), and use > autoconf to decide whether its needed at build time. I have to admit I am a Win32 guy (and closed source too) for too long to know autoconf - but I think I understand what it does. I'll keep up the Windows flag (well, not the easiest stand ;)) and throw these win32 warnings in whenever approriate. > What's more, if the implementation made a good easy-to-parse > encoding onto the syslog(3) message, this could be the > favoured implementation. Combine it with a syslog that fixes > the grossest defects of the standard one (replace the idiot > partial timestamps with ISO 8601 / RFC 3339; replace UDP with > TCP plus simple newline termination to delimit records) and > we'd be close to done, no? I think we do not need to break RFC3164. - Let's stick with the "idiot" timestamp in the header and provide an RFC3339 one as one tag. That way, we keep consistent with the rest of the world. And, yes, I would definitely like to see (and implement) a such simple RFC3164 over TCP as you suggest: plain 3164 EXCEPT - TCP is used - the message format stays as in 3164 - if one message is sent in a TCP session, there is no modification to 3164 format - if multiple messages are sent in a single TCP session, the second and all subsequent messages START with LF (or CRLF - well either one or the other). Please note the diffence to the original post: It was msgLFmsgLFmsgLF I changed it to msgLFmsgLFmsg (no LF because LF is only at the start of following messages) I think this format makes parsing easier and more consistent. Think about the end of the packet. What do we do if we do not see an LF if it should be at the end of the packet... This is at least consistent with what PIX does. As Andrew pointed out, however, PIX does NOT insert any kind of message termination, just a new <PRI> tag. Well, this might be the way to go as PIX is definitely wide-spread.... Bottom line: I vote for a very simple extension to 3164, but it should be really simple. In the long run, 3195 has its advantages and I would prefer to put ressouces to make BEEP easier to use than to write a new protocol. An simple 3164 extension as specified above is VERY easy to do - anthing else requieres proper engineering and thus ressources - at least from my point of view. > > If we're closing on an implementable design, would it be > worth giving some thought to the registration management for > the tags? We definitely do. And as it looks, IANA is not yet the place to use ;) > I think we're in agreement that we can't hope to > cover every possible need a priori, there needs to be some > open-ended flexibility for people to add tags where the > existing lexicon doesn't cover their needs. But we really > ought to try and find a way to encourage people who run into > that situation to submit their new tags to a registry that > feeds them back as updates expanding the lexicon --- and > ideally the submitter's code shouldn't have to change when an > updated lexicon comes out, it should continue just as before, > with its "private" tags coinciding with the new standard tags. Marcus: I think there were many positive comments on your logging map. Would you take on the registry path? Tina & Marcus: would loganalysis.org be *the* place to have this hosted... Just a thought... Other than that, how do others feel about fireing off an e.g. sourceforge project, which has the goal to first assemble the documentation and then an initial implementation? I could contribute some, but there are definitely some other needed to get it rolling.... Rainer _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:58:02 PST