on this issue, I think it is an agreeable compromise
... or may be not ;)
Rainer
-Original Message-
From: Anton Okmianski [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 12, 2004 11:39 PM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: RFC 3339 UTC offset
Rainer:
#1
Rainer:
In the light of this sum-up, I propose the following compromise:
- we will continue to use the rfc 3339 timestamp in its
unmodified way
- we will ignore that RFC 3339 calls for timesync (because
we can't ensure it)
- there will be NO header field indicating the reliability
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
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.
Actually, I think this is the easy part. Its a trivial solution, but I
think it works. I think we can require
Actually, I think this is the easy part. Its a trivial
solution, but I
think it works. I think we can require that a syslog
implementation - by
default - sets a I am not sure about my time flag. This is changed
only after the operator configures it to be differently.
This isn't really
On Thu, Feb 12, 2004 at 06:24:12PM +0100, Rainer Gerhards wrote:
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.
Actually, I think this is the easy part.
Rainer:
#1 is more a spec-stunt than a real solution ;)
In 4.4, RFC 3339 says
###
o Use another host in the same local time zone as a gateway to the
Internet. This host MUST correct unqualified local
times that are
transmitted to other hosts.
###
Definitely a
design them such that they could rfelect the values set via
other mechanisms, such as NTP.
dbh
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 11, 2004 8:48 AM
To: Anton Okmianski; [EMAIL PROTECTED]
Subject: RE: RFC 3339 UTC offset
Just
12, 2004 12:26 PM
To: Devin Kowatch
Cc: Anton Okmianski; [EMAIL PROTECTED]
Subject: RE: RFC 3339 UTC offset
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
Hi!
I will reply to various emails in one.
Who makes the assertion that you can trust my timestamp? An
application? As Devin points out, an application has no way
to determine whether a timestsamp is valid, and thus cannot
be trusted to make a valid assertion on its own.
Application can
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
11 matches
Mail list logo
