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

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

I don't object to date-time, provided the client provides the value in UTC, or local+offset.  What I see as my issue is requiring submission servers to understand the rules for every timezone for which one of it's supported clients may be configured.

However, as Eric noted, if the client needs to convert to UTC, then it has done the interesting work to getting to delta-time.  It is not worth implementing two nearly identical protocols mechanisms to save some simple addition or substaction.

I agree with Corby, that we should look at this as two problems.  A future-delivery service, with an intended use-case of days to weeks, and a calendar-based message triggering event. 

Distinctions between the two services may be as follows:
	- Calendar-based events don't take up space in MSA queues.  
	- Calendar-based events can be revolked by removing the event from the calendar
	- Calendars can do a good job of managing time-zones.

So, I propose we move foward with the futuredelivery draft with delta-time only (or UTC date-time only) and start work on a separate extension to the calendaring work to create a "send this message (with this envelope)" event.   That "send this message" would have nice synergy with the URLAUTH....

The choice of UTC vs delta-time seems only to require a choice between consequences of mis-configured client time and timezone.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Monday, September 19, 2005 8:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

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

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

---

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

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