RE: syslog-protocol-01 posted & comments

[Rainer Gerhards <rgerhards@hq.adiscon.com>]

Anton,

one more comment:

> > implementation will be out for many years to come. Obviously,
> > all real-world syslogds will need to support those older
> > clients - or they will not receive market acceptance.
>
> I think nothing prevents a syslog server implementation from complying
> with both RFC 3164 and RFC.new.

I think there is indeed a *big* issue. I may be totally missing the
obvious, but how can a syslogd - IN A STANDARD WAY - differntiate
between legacy syslog and -protocol? Its an honest question.

Hoewever, the only answers I have seen to similar issues so far is "look
at the headers and guess" - I think this is not good. Maybe we should
REQUIRE a specifc structured data element to be present, to say "hey,
this is new format" - this could solve it. Is that an idea?

A sample for a REQUIRED structured data element:

[#@syslog version="1"]

Everything that does not have this structued data element, MUST be
considered "old style", everthing that has it MUST be fully compliant
with -protocol. A syslogd just implementing -protocol is free to drop
all packets that do not have this element.

How does this sound?

Another approach may be to change the message format, eg. instead of

<PRI>......

-protcol may start with

[VERSION, FACILITY, SEVERITY]....

deliberately breaking compatibility.

Comments are highly appreciated.

Rainer