one more thing... I just got a - I think - good idea. We could say that by default, we don't fully trust the timestamp. Then, we could define an optional structured data element (hey, we've got those!) that says "yes, you can trust my time". This could also be extended for use by timestamper services.
Out of the options so far, I like this one most... Rainer > -----Original Message----- > From: Devin Kowatch [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 6:19 PM > To: Rainer Gerhards > Cc: Anton Okmianski; [EMAIL PROTECTED] > Subject: Re: RFC 3339 & UTC offset > > On Wed, Feb 11, 2004 at 06:35:28PM +0100, Rainer Gerhards wrote: > > Anton, > > > > this is a tough one ;) > > > > > Well, I think demanding that capability is more about host > > > implementation. I think it is better to focus on the > > > protocol and what > > > the client/sender must put into the UTC offset field if > one is not set > > > on the system. > > > > This is right. And I have to admit it is an important > issue. We always > > have nightmares about non-timesynced devices, as many > customers have. In > > fact, the default of our product is to use time of > reception, not the > > time from the message timestamp. I guess this shows it > actually *is* a > > real world issue... > [ snip ] > > The problem that I have with these solutions is that they require the > syslog daemon to know if the time and timezone on the machine > are valid. > I can't think of any way of doing that. I'd would be perfectly happy > with a recomendadtion that the hosts should hove the correct > time/timezone information. However, ultimatly it's the sys admin's > problem if their machines have incorrect time/timezone. And the sys > admin which will suffer for it. > > This isn't meat to trivialize the issue, but I don't think that it's a > problem which we should try to solve in the syslog protocol. You can > only do so much to protect people from them selves. > > My $0.02 > > -- > Devin Kowatch > [EMAIL PROTECTED] >
