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

From: "Eric Burger" <[email-masked]>
Date: Mon, 19 Sep 2005 07:53:21 -0400

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

---

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

> I was looking for a use case for "send this message 30 minutes from

I don't know of any, but since that's the case that delta-time does well, 
I assumed that it was important to some set of folks.

I think that we can all agree that if time on the client and server are 
synchronized, it doesn't matter if we have delta-time or date-time; both 
work.

A practical manner, the server is likely to store the request with the 
release time (as date-time) rather than maintaining a countdown on delta 
time.  Also, conversion between delta-time and date-time is not always 
straightforward due to summer time, leap seconds, etc.

If the client and server are not time-synchronized there is no way that 
the client can reliably have a message be held for a fixed interval if it 
only has date-time.  This is the one thing that delta-time does well.  I 
assumed that, since so many people wanted delta-time, that it had to be 
important.

The other side of the coin is that that if the client and server are not 
time-synchronized there is no way that the can can reliable have a message 
be released at a specific time if it only has delta-time.  This is because 
the client's clock is the one that is likely to be wrong.  Hence, this is 
something that date-time does well.

Punting on timezone and summer time issues by stipulating UTC time only is 
acceptable to me as a date-time advocate.

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 19 Sep 2005 17:43:54 +0200

Eric Burger writes:
> I was looking for a use case for "send this message 30 minutes from now."

I've done that a few times. 'sleep 7200; mail -s ...'. Right now, I 
remember two cases like that. Quite recently I did that to send mail 
about a bug I'd just fixed and have it be delivered only when the code 
had gone through a rather longwinded build/QA/regression process. Once 
I went home to prepare a party, and gave myself two hours to prepare 
before a "come and get it!" reminder went out. (I did not have network 
access at home at the time, unlike everyone else. Now I have IPv6 in 
the kitchen. Not sure it's improved my life.)

Come to think of it, I've often sent mail that I wanted to be delivered 
after a crontab runs or similar. To make up a generic example: "Hi, I 
just added so-and-so to the intranet, please comment", but the intranet 
is updated only once per hour, so you'd want that mail to be delivered 
in an hour, when the changes have become visible to the recipient(s).

My most important use-case personally is to send mail and have it arrive 
after the recipient leaves office, or not arrive while the recipient 
ought to be getting a life. Some people are all too easily coerced to 
spend the evening or weekend working.

Arnt