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

From: [email-masked]
Date: Mon, 19 Sep 2005 07:11:55 -0500

Is it the case that we want to split the work into two drafts?
draft-ietf-lemonade-futuredelivery-XX.txt
draft-ietf-lemonade-calendardelivery-XX.txt (:P)

The reason I ask is that CalSify is trying to solve for a similar
problem for the TZ issue and I wonder if we want to wait to see what
their solution will be where the creator, server, and participant of a
meeting are all in different time-zones.

Additionally, the two mechanisms are sufficiently disparate from each
other that they may warrant two different drafts.

If we split it we can get futuredelivery done quickly and then
concentrate on the TZ problem.

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Eric Burger
> Sent: Monday, September 19, 2005 07:53 AM
> To: Mark Crispin
> Cc: [email-masked]
> Subject: RE: [lemonade] I-D 
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> Actually, these are all good, real, and expected use cases.
> 
> I was looking for a use case for "send this message 30 minutes from
> now."
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
> Crispin
> Sent: Sunday, September 18, 2005 9:35 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [lemonade] I-D
> ACTION:draft-ietf-lemonade-futuredelivery-02.t xt
> 
> On Sun, 18 Sep 2005, Eric Burger wrote:
> > Examples, please
> > Original Message From: Mark Crispin
> > > Actually, I've come to believe that we need both.  I can think of
> usage
> > > scenarios when I want to hold delivery for 30 minutes, and usage
> > > scenarios when I want to hold delivery until after such-and-such
> time.
> 
> I often queue messages that I want to deliver after some time in the 
> future.  Most recently, when I was gone for a month of 
> vacation without 
> much likelihood of Internet access, I queued several messages to be 
> delivered during the time that I was gone.  This included everything
> from 
> birthday greetings to reminder messages.  Some of these were sent as 
> regular email, others as SMS via email-to-SMS gateways.
> 
> Don't forget, not everybody uses a calendaring application.  Family 
> members, in particular *youthful* family members, tend to be 
> quite email
> 
> savvy yet can not be relied upon to check a calendar.
> 
> In 35 years, I've used no less than *three* pre-UNIX operating system 
> environments which had this feature (we called it "reminders").  I run
> one 
> of these operating systems to this day, albeit under 
> emulation.  One of 
> its important production tasks is to support my delayed 
> deliveries.  [I 
> also use the UNIX calendar program and Outlook.  I use the 
> appropriate 
> tool for the task.  Anyone who claims that one is always 
> "best" probably
> 
> also uses a screwdriver as chisel.]
> 
> Those systems, by the way, used date-time, never delta-time.  
> This was 
> understood to be "local time"; and since there was no client/server
> split 
> this was not a problem.
> 
> Although the arguments for delta-time in Lemonade *are* 
> compelling, they
> 
> are undermined by the observation that most servers are likely to
> convert 
> delta-time into a date-time for queuing rather than have the 
> delta-time 
> countdown in real-time.
> 
> Consider what has to be done to queue a message to be delivered after
> 8AM 
> on 14-Nov-2005 if you only have delta 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: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 19 Sep 2005 13:59:55 -0500

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

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 19 Sep 2005 16:08:28 -0500

This feels like 20 minutes in a face-to-face would resolve this :-)

In neither case does the server have to do TZ math.  At that level both are equivalent.  The only time TZ math is needed is for the client to provide a more user friendly interface than specifying a raw interval or manual UTC time entry. (how many joe-users know what UTC is???)  

Marc, I don't accept that date-time gets the client out of having accurate time configuration.  At a minimum, the client needs to know it's offset from UTC.  To determine that, it needs at a minimum to know what timezone it is in and whether or not it is in summertime.  To do know that, you need an accurate clock with the correct date and time.

Greg V.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark Crispin
Sent: Monday, September 19, 2005 3:39 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

On Mon, 19 Sep 2005, [email-masked] wrote:
> 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.

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.

> This makes it quite easy to think about since, as Greg pointed out, TZ,
> 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.

---

From: [email-masked]
Date: Wed, 21 Sep 2005 09:04:19 -0500

Depends on the network.
All networks in europe supply TZ information.
In the US it depends, but it's getting better.

Corby Wilson

> [mailto:[email-masked]] On Behalf Of ext 
> Vaudreuil, Greg M (Greg)
> Sent: Wednesday, September 21, 2005 09:14 AM
> To: [email-masked]
> Can anyone on this list tell us if the mobile network (GSM 
> and/or CDMA) provides timezone information to the handset 
> along with local time?
> 
> Greg V.
> 
> Behalf Of Arnt Gulbrandsen
> Sent: Wednesday, September 21, 2005 6:39 AM
> To: [email-masked]
> Cc: Eric Burger; Lyndon Nerenberg
> Subject: Re: [lemonade] I-D
> Lyndon Nerenberg writes:
> > On Sep 19, 2005, at 8:24 PM, Eric Burger wrote:
> >
> >> Once that is magically done, the protocol using UTC or 
> delta-time is
> >> identical.  Pick one and only one, please.
> >
> > The UI implementation issues are irrelevant. What this 
> boils down to,  
> > at the protocol level, is:
> >
> >     Who's time do you trust? The clients or the servers?
> >
> > If you answer "the client" then you use deltas; If you answer "the  
> > server" then you use (absolute) UTC. They aren't mutually 
> exclusive,  
> > they are complimentary.
> 
> Aren't you assuming that the client's timezone is reliable? If the 
> client asks its user in local time and tells the server in UTC, it 
> needs an accurate time zone.
> 
> If the timezone is wrong and the local time is right, that problem 
> doesn't usually show up, so it can remain undetected for quite some 
> time.
> 
> Arnt
>