Re: [logs] Syslog payload format

From: Mikael Olsson (mikael.olssonat_private)
Date: Tue Jan 07 2003 - 03:17:49 PST

  • Next message: Rainer Gerhards: "RE: [logs] EventLog library"

    Rainer Gerhards wrote:
    > Is there agreement on only a slight extension to
    > support TCP? Let me sum up:
    > It is RFC3164 except:
    > - TCP is the transport
    > - messages MUST end with (CR)LF - should it be LF or CRLF?
    The "Internet standard" is CRLF.  Most protocols do use CRLF, but, then
    again, most daemons also happily accept LF.  Make it an either/or for 
    senders, where receivers MUST accept both?
    > - the timestamp MUST be RFC3339
    > - there MAY be multiple messages within a single TCP stream
    > - client and/or server are free to disconnect the stream when they see
    > fit
    Agree. A couple of things:
    - What about messages "terminated" by end-of-stream?
      Assume that they're broken and shouldn't be stored, or assume that
      EOS is a valid terminator?  (I just think that a "SHOULD" would be
      in place, here.)
      My suggestion: EOS means "broken message", so the "messages MUST end 
      with (CR)LF" really means _must_.  This makes it easier for receivers;
      if their socket layer is too hidden from view, it may be hard to 
      differentiate between "graceful FIN handshake" and "connection b0rken".
    - A less-than-important thing: a standard port number would be 
      nice, but 514/tcp is officially taken :/   
    - Explicitly: high resolution timing is valid but optional, so
        2003-01-05T12:08:50.12345678+01:00  and
        2003-01-05T12:08:50+01:00  are both valid
      (This is in full compliance with rfc3339, but I think it 
       deserves to be mentioned.)
    > - not compliant with what PIX does!!! (should we allow an alternate
    > termination to take care of this -- I would suggest so as the PIX is
    > definetely important and chances are great we'll write code to support
    > it anyhow...)
    I'd say "use a different port for PIX logging".
    Cisco's scheme is, as far as I understand it: 
      <123>event 1 blah blah blah <123>event 2 blah blah <123>event 3 ...
    This works for a single source->destination scenario, but not for 
    a source->relay->destination scenario, so I for one don't want to 
    bless it officially.  (Hi, Chris. :))
    > - Who will support it? (this is the big one ;-))
    One firewall and one minimalistic syslogd here 
    (the latter not public yet ... soon, though).
    Mikael Olsson, Clavister AB
    Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
    Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
    Fax: +46 (0)660 122 50       WWW:
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 08:09:06 PST