Re: [Syslog] Small draft for Syslog File Storage?

[Simon Josefsson <[e-mail]>]

"Rainer Gerhards" <[e-mail]> writes:

> Hi all,
>
> In what we did, we specified the on-the-wire format. However, we did not
> specify any format to use when persisting syslog data to a file.
>
> Note that we were very generous when specifying the on-the-wire format, for
> example we permit LF, CR, NUL and many other characters considered dangerous
> in file formats.
>
> There are many tools available which interpret syslog data stored in text
> files. However, different syslog implementations may use slightly different
> file formats.
>
> Together with the control character issue, the file format question both has
> interoperability AND security issues. I think these would be very easy to fix
> if we write a small RFC that specifies how text is to be encoded. It would be
> similar, but much smaller to RFC4627 (JSON). Actually, I think we would need
> to carry over primarily its section 2.5.
>
> I would volunteer to write an initial draft, but would first like to get some
> feedback if this effort has any chance of getting through.

I would support that effort.  Multiple incompatible syslog formats are a
pain, and it has bitten me several times in multiple jobs.

One approach that would be easy to move forward with is that you write a
document registering a MIME media sub-type, e.g., text/syslog or
application/syslog.  Describing one reasonable syslog text format in
that document.  With this approach, there is less pressure on all syslog
vendors to agree on a particular format, and you can just invent one
format that makes sense and let people adopt it on an opt-in basis.
I've registered some MIME media types, and learned some details when
doing that, so I could help with this approach if you want.  Having a
MIME media type specified would also enable reliable transfer of syslog
data in protocols that are MIME aware (e.g., HTTP or e-mail).  With this
approach, there is also less of a requirement to be backwards compatible
with existing (often sub-optimal) formats.

/Simon