Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

From: [email-masked]
Date: Mon, 19 Sep 2005 12:13:51 -0500

In order to handle date-time delivery, one must always assume the worst
case:
1) The client time is NOT synchronized with the server.
2) The client TZ is NOT the same as the server.

A typical example is a server in New York (UTC-5:00) and the user in New
Delhi, India (UTC+5:30). (Kathmandu is UTC+5:45!)

When a user sets a "send on HH:MM DD/MM/YY" request he will be using the
client clock to set this, not the server clock (since he can't see it).

We can safely assume that most mobile devices that are linked to a
cellular network have synced clocks to the network clock.  This is
becoming more true for laptop and desktops as Windows XP and Mac OS X
both default to synchronizing the clock with an NTP server.  But the
assumption can not be made for the worst case scenario.  We simply can
not fix this and we shouldn't try.

To make matters worse, governments get in there to mess things up even
more.  Countries shift time zones of cities to fit better into the
global market, governments shift the DST rules under the illusion that
it will save energy.  The TZ and DST rules are not static.

So the one solution that will give us the least ammount of error most of
the time is having the client convert the time into UTC before sending
the request to the server.  This way the server always has a base from
which to start with out needing to know any additional infomration about
the client such as what TZ it is in or if DST applies.  It is up to the
application vendor to make sure the client clock is set correctly and
that the application uses the correct time to convert to UTC.

What this allows us to do is have the client perform the calculation
before sending it to the server.  The user sets a message to be sent on
Dec. 25, 2005.  The client calculates the UTC date-time to send the
message and sends the request to the server.

This method also works for deltas.  The client calculates the UTC+delta
time and sends the request to the server.  This way the server just has
to maintain a list of event triggers.

Personaly I don't think it's worth it to add anymore complexity to the
futuredelivery system than this.  The return is too small for the
enormeous complexity we need to add to the server to get this to work
most of the time.  If the user is too confused when using it, he will
stop using it.

My two cents :)

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Mark Crispin
> Sent: Monday, September 19, 2005 12:23 PM
> To: Vaudreuil, Greg M (Greg)
> Cc: [email-masked]
> Subject: RE: [lemonade] I-D 
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> On Mon, 19 Sep 2005, Vaudreuil, Greg M (Greg) wrote:
> > However, as Eric noted, if the client needs to convert to 
> UTC, then it 
> > has done the interesting work to getting to delta-time.
> 
> This assumes, incorrectly, that the client necessarily did 
> the conversion.
> 
> This also assumes, incorrectly, that the client is guaranteed to have 
> accurate knowledge of the current time, and how to convert 
> that time to 
> UTC.
> 
> > It is not worth 
> > implementing two nearly identical protocols mechanisms to save some 
> > simple addition or substaction.
> 
> This statement staggers me.  To get date-time arithmetic right, a 
> programmer must follow many non-obvious requirements.  
> Decades of history 
> of date-time arithmetic bugs contradicts the claim that it is 
> "simple".
> 
> I spend a lot of my time developing date-time arithmetic routines.  I 
> think that I do it rather well, but I don't pretend to be an expert. 
> Rather, I find it to be a continually humbling lesson on how little I 
> know.
> 
> What's more, if it is "simple" then you have just undermined 
> the argument 
> for delta-time.  Most (all?) servers will store the request 
> with a release 
> date-time, and some fraction of human requests to the client 
> will be with 
> a release date-time as opposed to a delta-time.
> 
> Use of delta-time requires *two* conversions (which must be 
> mirror images 
> of each other on client and server) when the human wanted a 
> date-time. 
> All this just to move the delta-time -> date-time conversion from the 
> client to the server when the human requested a delta-time.
> 
> Now, if you argue that the conversion is not simple, or that 
> the client 
> may not have synchronized time, you've just contradicted yourself.
> 
> If it is "simple" *AND* the client has synchronized time, 
> then date-time 
> should be the one and only mechanism because it has either 
> zero or one 
> conversion.  Delta-time always has at least one conversion, 
> and use cases 
> have been supplied that require two conversions.
> 
> If it is not "simple" *OR* the client lacks synchronized 
> time, then you 
> need both date-time and delta-time.  You can't do any 
> conversions on the 
> client, and the humans can enter requests both to "delay for a fixed 
> interval" and "delay until a fixed time."
> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 19 Sep 2005 10:37:41 -0700 (PDT)

> 2) The client TZ is NOT the same as the server.

Correct.

That's why the date-time proposal specifies UTC time.

> client clock to set this, not the server clock (since he can't see it).

Incorrect.  Why do you assume that he is using either a client or server 
clock?

> the request to the server.

Correct.  But note that this is not necessarily the same as "convert the 
client's time."  This does not even require the client time.

> message and sends the request to the server.

This could be as simple as accepting the user's input as UTC.  A bit 
fancier is to look up a nearby major city in a table to get its timezone 
(LG phones have this).

In no case does it require the client's time.  If I queue a message for 
release on Dec. 25, 2005, it is irrelevant in a date-time request what the 
time now is.

> to maintain a list of event triggers.

This is only true if the client and server have synchronized time.

> most of the time.

What is this "enormous complexity" of which you speak?

Are you saying that it is too difficult to parse a date-time?  That's a 
surprise to any IMAP server implementor.  The fact that the date-time is 
in UTC makes it easier than the task on IMAP?

Are you saying that it's "enormous complexity" to parse a delta time, add 
it to the current time, and save that as a future date-time?  I agree that 
this is additional complexity.  But it isn't enormous, and there's 
evidence that it would help out the people who want to delay for 
short-term intervals.

Are you an SMTP server implementor?  I am.  In fact, I wrote one of the 
oldest still-running SMTP server implementations.  I see no problem with 
adding date-time.  Delta-time will be annoying, but not too bad.

It's the clients that I worry about, and the lack of client choice.

Speaking now with my client hat on, I am EXTREMELY concerned about being 
forced to send delta-time when I really want to send a date-time.  I have 
NO use cases for delta-time, but I'm willing to go along with it because 
some people seem to think that it's important.

> If the user is too confused when using it, he will
> stop using it.

Hence the requirement for date-time.  Your client does not have to use it 
it it doesn't want to; it can choose to use delta-time exclusively.

But if date-time is not available in the protocol, I predict that there 
will be bugs, and that users will be frustrated when their long-term 
messages are released at other than their intended time.

H. G. Wells' epitaph comes to mind.

-- Mark --

http://panda.com/mrc