Subject: [lemonade] futuredelivery: client/server time sync problems

From: Cyrus Daboo <[email-masked]>
Date: Thu, 27 Oct 2005 11:11:14 -0400

Hi folks,
The issue of client and server times being out-of-sync has been discussed 
before wrt FUTURERELEASE (aka FUTUREDELIVERY). That is a problem if the 
client wants to 'until' option and specify a UTC time. Often client 
machines are not setup correctly with the proper local time info so that 
UTC calculation on the client side made be incorrect.

One simple solution to this would be to have the server return its current 
UTC time in the FUTURERELEASE EHLO response. This would allow clients to 
use a UTC time based on the server's value rather than its own. Or at the 
very least throw up a warning to the user if the client and server times 
are significantly different.

Note that having the server provide its value of UTC may eliminate the need 
to have two release methods as described in section 4.1 of the current 
draft.

-- 
Cyrus Daboo

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 Oct 2005 16:55:59 -0700 (Pacific Daylight Time)

On Thu, 27 Oct 2005, Cyrus Daboo wrote:
> client wants to 'until' option and specify a UTC time. Often client machines 
> are not setup correctly with the proper local time info so that UTC 
> calculation on the client side made be incorrect.

The presumption with this problem statement is that the desire is to delay 
for an interval.  If I want to delay until a specific time, it is of no 
consequence what the setting is of the mobile device's time.

There is one possible exception:

If I, as the user, say "send this after 6PM Seattle time", then my mobile 
device needs to know what "Seattle time" means.  Many mobile devices have 
a "world clock" feature that can do this; however there's a question of 
current summer time phase.  If the "world clock" knows the summer time 
rules, then the mobile device must know the day accurately (or at least 
within the current phase).  Most "world clocks" require the summer time 
phase to be set manually by the user.

> One simple solution to this would be to have the server return its 
> current UTC time in the FUTURERELEASE EHLO response.

This begs the question of what should happen when (not if) this time fails 
to match:
  . the mobile phone network's time
  . the time obtainable from credible NTP servers
  . the time obtained from GPS

We can simplify matters by saying that GPS time always overrides time from 
an Internet time server.  We can also say that in the case of GSM 
networks, mobile phone network time is always disregarded in favor of GPS 
time or NTP time; unfortunately we can't do that in the case of a CDMA 
network.

However, no matter how we look at it, there's at least two, possibly 
three, times that the device must keep track of.  I'm not sure that the 
extra complexity is worth it.

I also don't see how it's significantly better to synchronize with the 
submission server instead of requiring that both client and server 
synchronize with GPS or NTP.

In particular, we should stipulate that the client MUST synchronize with 
GPS or NTP and not use a mobile phone network time that may have been set 
from some operator's watch.  Even a CDMA network may have bogus time 
(especially if it's in an island with no other network).

> to have two release methods as described in section 4.1 of the current draft.

Not unless you force the client to synchronize with the server.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.