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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 20 Sep 2005 07:08:26 -0500

I agree with Mark that there is ONE use-case where date-time provides functionality that can't be met with delta-time is when:

	a) Client does not have accurate time
	  - and -
	b) Users are knjow enough to enter UTC, either directly, or by knowing their offset.

I content that "B" probably includes Mark and about another thousand people :-) .   The rest of us will buy a client or a mobile computing device that can figure out what time it is.  I personally don't keep track of my UTC offset... and usually forget to adjust my clock forward in the spring.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mark Crispin
Sent: Tuesday, September 20, 2005 12:17 AM
To: Eric Burger
Cc: [email-masked]
Subject: RE: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

On Mon, 19 Sep 2005, Eric Burger wrote:
> Thinking about it some more, the hardest part is converting the request
> into UTC.

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.

> Once that is magically done, the protocol using UTC or delta-time is
> 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
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: Mark Crispin <[email-masked]>
Date: Tue, 20 Sep 2005 08:22:39 -0700 (PDT)

On Tue, 20 Sep 2005, Vaudreuil, Greg M (Greg) wrote:
> I agree with Mark that there is ONE use-case where date-time provides 
> functionality that can't be met with delta-time is when:

The (b) condition is incorrect, and was stated to mislead.  The question 
of whether the user knows enough to enter UTC, or if the phone knows how 
to convert it, is a red herring.

The correct (b) condition is:

(b) The user wants to release at a future time, rather than a fixed 
interval.

-- Mark --

http://panda.com/mrc