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

From: [email-masked]
Date: Mon, 19 Sep 2005 14:25:24 -0500

The way I was looking at delta was that with delta the time on the
client and server had no effect what so ever.
The client and server times play no role at all.
Sending the delta to from the client to the server simply means that the
user wishes to send the message N minutes from NOW, where NOW can be any
time, whether it's server or client time.
This makes it quite easy to think about since, as Greg pointed out, TZ,
DST, and ST/CT don't matter at all.

However, implementation does play a role and this would generate two
different mechanics.

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext 
> Vaudreuil, Greg M (Greg)
> Sent: Monday, September 19, 2005 15:00 PM
> To: Mark Crispin
> Cc: [email-masked]
> Subject: RE: [lemonade] I-D 
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> 
> Glad we are coming to agreement on UTC.  The question for me 
> is Delta-time vs UTC from Client.  I don't know why 
> delta-time is more complex than UTC, and will assume for now 
> they are equivalent.
> 
> - If client and server are properly configured, the solutions 
> are equivalent.  (future - current = delta)
> - If clients are mis-configured, Wrongs things may happen.
> 
> CLIENT HAS WRONG TIME, RIGHT TIMEZONE
> 
> A) UTC
>    - Client will translate requested time into UTC, using 
> local TZ settings.  Server gets 
> 	the desired time in UTC and releases for delivery at 
> the requested time.
> B) Delta-time
>    - Client computes difference between future time and 
> current, and sends delta.  Server 
> 	translates into UTC and releases message as early or 
> late as the client's clock error 
> 	effects.
> UTC wins.
> 
> CLIENT HAS RIGHT TIME, WRONG TIMEZONE  (i.e., user changes 
> clock when traveling, but does not change TZ)
> 
> a) UTC
> 	- Client computes UTC with the wrong local timezone, 
> resulting in submission earlier or later 
> 	  than intended, depending on the nature of the TZ error.
> b) Delta-Time
> 	- Client subtracts current time future time.  TZ not 
> considered in calculation, message
> 	  delivered on-time.
> 
> Delta-time wins
> 
> 
> Personally I prefer delta-time because I am much more likely 
> to have time-zone screwed up than to have an incorrect clock. 
>  I am regularly flipping home and away timezone to understand 
> calendar requests.  Before I learned to do that, I used to 
> just change the time on the computer... so the time was 
> locally correct but the TZ was still home-time.  
> 
> I can live with either, but not both.
> 
> Greg V.
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Mark Crispin
> Sent: Monday, September 19, 2005 2:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [lemonade] I-D
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> 
> On Mon, 19 Sep 2005, [email-masked] wrote:
> > The complexity I was refering to was to have the server 
> determine the TZ
> > of the client and calculate into UTC.
> > It sounds like we all agree that sending UTC is the 
> solution to use, so
> > the complexity would be avoided.
> 
> OK, then, we're on the same wavelength, at least on that point.
> 
> I don't think that anyone has seriously suggested sending a 
> date-time in 
> any TZ other than UTC for quite a while.  So yes, we all agree that 
> sending UTC is the solution to use.
> 
> What may have been confusing was that in the past, some of us 
> thought that 
> it would be alright to send a date-time in RFC 2822 or IMAP 
> INTERNALDATE 
> format; that is, with a mandatory TZ tag.  Although that is 
> effectively 
> equivalent to sending UTC time, it raises too many issues of 
> confusion. 
> So you can consider that to be a dead idea.
> 
> -- 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
> 

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 19 Sep 2005 12:38:39 -0700

> time, whether it's server or client time.

Agreed.  Now, please consider the following (your argument, with a few 
words changed):

The way I was looking at date-time was that with date-time the time on the
client and server had no effect what so ever.
The client and server times play no role at all.
Sending the date-time to from the client to the server simply means that the
user wishes to send the message at such-and-such a time, no matter what 
the time may be (or not be) on the client or server.

I think that this is also a valid argument.

It all depends upon what the user wants to do.  If you only have the one, 
a user who desires to do the other is forced to do a conversion, which in 
turn requires client and server times to be synchronized.

We have use cases of a user wanting to do each of these.  We also have 
compelling testimony that we can't assume that the clocks on the client 
and server will be on the same page (or even that the client will have a 
clock!).

Thus, we need the server to offr both.  That way, the client can use which 
method is more suitable for the particular case at hand.

I envision that an advanced client might be capable of sending both forms, 
based upon the situation.

Although an advanced client probably has a synchronized clock and can do 
the conversion, it might not want to depend upon that.  And anyway, it's 
less work to send what is intended rather than worry about doing the 
conversion and maybe blundering in some way.  After all, summer time is 
quite difficult to convert properly since it's a moving target.

> DST, and ST/CT don't matter at all.

Correct in both cases, as long as date-time is always UTC.

-- Mark --

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