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

From: "Eric Burger" <[email-masked]>
Date: Mon, 19 Sep 2005 23:24:28 -0400

Thinking about it some more, the hardest part is converting the request
into UTC.

Once that is magically done, the protocol using UTC or delta-time is
identical.  Pick one and only one, please.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vaudreuil, Greg M (Greg)
Sent: Monday, September 19, 2005 9:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

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

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

---

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

> Thinking about it some more, the hardest part is converting the request

The only thing that need to be done is apply the UTC offset for a future 
time.  Either:
  . the user does this, and enters a UTC time.  If I want 9AM, I know quite
     well that that time is 16:00 UTC in the summer and 17:00 UTC in the
     winter.
or
  . it's done by a table lookup.  My LG phone has a list of cities and UTC
     offsets, although it needs to be told whether or not to apply DST.

There is NO calculation here, and NO local knowledge required of the 
current time.

> identical.  Pick one and only one, please.

This is the hard problem.

The protocol is identical ONLY if the client has synchronized time with 
the server.

Since it has been stated (repeatedly) that we can not assume that the 
client has synchronized time with the server, this has the following 
consequences:

1) If the user wants to release at a specific date-time, the client can
    NOT calculate delta-time.  If the protocol only offers delta-time, then
    the client can not function.

2) If the user wants to release after a specific internal, the client can
    NOT calculate date-time.  If the protocol only offers date-time, then
    the client can not function.

There is NO single choice that works if the client does not have 
synchronized time with the server.  It is impossible to convert between a 
date-time and a delta-time without having synchronized time.

Let me emphasize this: if the human user asks to release a message at 9AM 
on Christmas, it is IMPOSSIBLE for the client to do this with a delta-time 
only protocol unless the client knows exactly what time it is now. 
Otherwise, the client will calculate an incorrect delta-time.

If you insist upon the protocol having one, and only one, of date-time or 
delta-time, then the protocol must stipulate that the client have 
synchronized time with the server.  Thus, we need to add yet another SMTP 
extension in order to fetch the server's time, so the client can be 
synchronized with it.

-- Mark --

http://panda.com/mrc

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 20 Sep 2005 18:12:05 -0700

> 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.

--lyndon

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Sep 2005 12:39:27 +0200

> server" then you use (absolute) UTC. They aren't mutually exclusive,  

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Sep 2005 07:48:50 -0700 (PDT)

On Wed, 21 Sep 2005, Arnt Gulbrandsen wrote:
> 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.

You are making the false assumption that the client's time or timezone 
figures into a future-time setting at all.  The whole point of sending 
date-time is that the client does not need to know the current time or 
timezone.  All it needs to know is the desired future-time and timezone.

Some phones have a "world clock" tool which, given network time, will show 
you the time in any of a long list of cities.  That tool's list of cities 
and their timezone is all that's needed to calculate the UTC time for a 
future-time.  The current [network] time is not used at all.

It is also a false assumption that delta-time can be calculated correctly 
without the client knowing correct time and timezone.  Every argument 
about the uncertainty of client time[zone] hammers nails into the coffin 
of delta-time for any use other than "block for 30 minutes".

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Sep 2005 17:21:32 +0200

Mark Crispin writes:
> figures into a future-time setting at all.

I'm actually assuming that the future-time is be specified in the 
client's timezone, ie. that some/most clients do it roughly the same 
way as Eudora (see appended screenshot, courtesy of Anthony Bowesman).

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Sep 2005 11:03:04 -0700

On Wed, 21 Sep 2005, Arnt Gulbrandsen wrote:
> I'm actually assuming that the future-time is be specified in the client's 
> timezone.

I don't make that assumption at all, especially not with mobile clients. 
In fact, I would probably want my future-time timezone to be my "home" 
timezone (maybe set during initial user configuration), which is 
completely different than the timezone my phone happens to have right now.

This is the important difference between setting a time at a fixed 
interval from now, vs. a future time.  It's necessary to recognize that 
there is a need to do both.  If you only recognize one of these scenarios, 
you end up talking past people who see the other (or both) without 
comprehending.  Which is what has been happening.

The fallacy of saying that either is "good enough" is the presumption of 
correct knowledge of the necessary inputs to do the calculation.

If that presumption is valid, then neither delta-time nor date-time have a 
definite advantage over the other.  In either one, some cases will require 
a calculation and others will not.

However, if that presumption is invalid, then there are some cases which 
can only be solved by the one and not by the other.

The compelling advantage of having both in the protocol is that the client 
NEVER needs to presume knowledge that it may not have, and further the 
client NEVER needs to do a calculation.  It simply uses the method that 
avoids the calculation.

If most of your client's use cases require a calculation to do date-time, 
you will howl in rage at the suggestion that you can't use the 
calculation-free delta-time.  And you would be right to do so.

Please recognize the other side: some of us have most of our use cases 
that require a calculation to do delta-time.  We are howling in rage at 
the prospect that we can't use the calculation-free date-time.

There is a solution.  We've spent much more time talking about it than 
would ever have been expended in doing it.

As Lyndon observed, it's absurd, even comical, to argue that it would be 
an excessive implementation burden on the SMTP server to do both.  I also 
agree with Lyndon's observation such an argument does not enhance the 
credibility of the IETF.

-- Mark --

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

---

From: Chris Newman <[email-masked]>
Date: Wed, 21 Sep 2005 15:18:58 -0700

Arnt Gulbrandsen wrote on 9/21/05 17:21 +0200:

> timezone, ie. that some/most clients do it roughly the same way as Eudora
> (see appended screenshot, courtesy of Anthony Bowesman).

The base "defer until" spec should support offset-time and RFC 3339 time.  We 
can add support for "future local time" at a later date, it can't be in the 
base spec.

In early drafts of RFC 3339, I had included a format for future local time 
specifications.  But we couldn't get consensus on that part of the spec, so it 
had to be excised.  Now that iCal tried the approach of including the zone 
rules with the object and learned that makes the interop problem worse rather 
than better, it's possible we could get consensus on something more sensible. 
But that would could add a year or more to the time it would take to complete 
this specification.  I don't think we should wait for that.

The problem with future local time is that it's non-deterministic.  The rules 
to convert from a given future local time to UTC can change at the whim of 
human governments.  So even if we get clients with perfect clocks, there's 
still a use case for future local time because the conversion to UTC loses 
information.  So I support adding it eventually, just not in the base "defer 
until" spec.

                - Chris

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Sep 2005 15:41:07 -0700 (Pacific Daylight Time)

> information.  So I support adding it eventually, just not in the base "defer 

Good points, and I agree with all of them.

Fortunately, UTC time can satisfy much of the need for future local time. 
I think though that you're right, and eventually we'll need three choices:
  . delta-time from now (fixed interval)
  . future UTC time (fixed time)
  . future local time (time with unknown variables)

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Sep 2005 06:20:22 -0700

At 11:03 AM -0700 9/21/05, Mark Crispin wrote:

>  The compelling advantage of having both in the protocol

Given the debate so far, and the small implementation burden on the 
server, I'd be happy to make both mandatory.  (If it does turn out 
that only one of the two is actually used, we can drop it when we go 
to Draft.)

I was one of those who originally said we should pick one to simplify 
the protocol, but I find the arguments for doing both compelling 
compared to the low cost.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
When a cat is dropped, it ALWAYS lands on its feet; and when toast
is dropped, it ALWAYS lands with the buttered side down.
Therefore, I propose to strap buttered toast to the back of a cat.
When dropped, the two will hover, spinning inches above the ground,
probably into eternity. A "buttered-cat array" could replace
pneumatic tires on cars and trucks, and "giant buttered-cat arrays"
could easily allow a high-speed monorail to link between New York
with Chicago.              --winner of the "new scientific theories"
                                 contest sponsored by Omni magazine.