RE: [logs] Syslog payload format

From: Rainer Gerhards (rgerhardsat_private)
Date: Fri Jan 03 2003 - 08:59:55 PST

  • Next message: Rainer Gerhards: "RE: [logs] Syslog payload format"

    > 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
    Please note the diffence to the original post:
    It was 
    I changed it to 
       msgLFmsgLFmsg (no LF because LF is only at the start of following
    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 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....
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:58:02 PST