On Mon, Jan 26, 2004 at 06:33:17PM +0100, Rainer Gerhards wrote:
> 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:
>
> [EMAIL PROTECTED] 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.
I was actually about to suggest that you add a version field to the new
protocol (maybe start it at 2?). So that changes could be made eaiser
in the future.
Also, I _really_ like the idea of making the new format differ from the
old format in a very well defined way, which is early in message. This
would make shifting the message to either an old style parser or a
-protocol parser easier.
>
> 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.
Okay, rather than go back and reply to the various messages that have
brought up compatability, I'll lump my comments in this one.
The behaviour I have observed from linux syslogd, and solaris syslogd is
the following. They will send messages formatted as:
<PRI> TAG: MSG
I don't recall if there is a timestamp in the message as sent. The
missing information is added by the reciever. This information is also
added before writing to a file. Under solaris at least, the syslogd
server will always add a host name after the timestamp. So if the
syslog sender, spits out:
<PRI> TS HOST TAG: MSG
solaris syslogd will write (to it's file):
TS HOST HOST TAG: MSG
I guess that the point to all of this is that we are almost garenteed to
break backwards compatibility. The philosophy that I have designed my
syslogd implementation with is to try and recieve all the old style
messages, but not worry too much about behaving like an old style
client. As such I would very much like to have an easy time
distinguishing between old style and new style messages to make the
parsing easier. But Don't care too much about being able to send new
style messages to stock syslogd implementations.
--
Devin Kowatch
[EMAIL PROTECTED]
