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...

> We can't tell them to put "-00:00" or "+00:00" as this
> has special meaning in the RFC. I would say that UTC offset if a MUST,
> while time sync is a SHOULD. If offset is not a MUST, then we MUST
> specify what they put as offset to indicate it is unknown.
> Yaks. Crappy
> little rule? :)

I spent some time reading and re-reading RFC 3339 and thinking how this
could be handled... I think all "clean" options are already used up.

I see three approaches:

#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.
   ###

   If I look at syslog, that means we can require all systems that don't
know
   their TZ to talk to a syslog relay which does. That, of course
   means we leave everything as imperfect as it is (but it
   is within the specs ;)).

OK, now to the solutions...

#2 is to "tweak" the format a little bit. Honestly, I don't like this
messing with a standard, and this is very far to the edge...

All special sequences (like "-00:00") are already taken up. 3339,
however, specifies that the "Z" UTC indicator can be either upper or
lower case. I have choosen to allow only upper case for simplicity. We
*could* say that if the device does not know its ZT and does not know if
time is properly synced, it should use "z" (lower case) as the TZ
indicator. This would still be a valid 3339 indicator, but definitely
not be in the spirit of 3339.

#3 is to actually add a syslog header field "I know my TZ info or I am
synced" (Y/N) in -protcol, eventually adjecent to the timestamp field.
Honestly, this, too, does not smell really good to me.

In any case, I think we have a real-world problem and it would be good
to find a solution. Which options does the WG prefer? Or is there
another one I have not seen so far?

Thanks,
Rainer

PS: I have listed this as issue 12 now.


Reply via email to