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

From: "Eric Burger" <[email-masked]>
Date: Wed, 21 Sep 2005 19:01:11 -0400

Given that all of the use cases for future release-for-delivery(tm) are specific time-based, I'm leaning heavily toward UTC only.

The earlier e-mail with delta-time release use cases, namely 'send after folks get home' or 'send when traffic ebbs', seem to me to really be absolute time-based.

Anyone for UTC only?

 -----Original Message-----
From: 	Mark Crispin [mailto:[email-masked]]
Sent:	Tue Sep 20 00:17:25 2005
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

---

From: Chris Newman <[email-masked]>
Date: Wed, 21 Sep 2005 16:22:32 -0700

I believe we have rough consensus to implement both RFC 3339 and offset-based 
for this.

Compelling technical arguments have been made that both provide independent 
utility.

No server implementer has objected to implementing both (because a server with 
a clock can trivially convert).

Client implementers have their choice if servers implement both and thus 
wouldn't object.

Let's stop wasting time and move on to more important issues.

                - Chris

Eric Burger wrote on 9/21/05 19:01 -0400:
> Given that all of the use cases for future release-for-delivery(tm) are
> specific time-based, I'm leaning heavily toward UTC only.
>
> The earlier e-mail with delta-time release use cases, namely 'send after
> folks get home' or 'send when traffic ebbs', seem to me to really be absolute
> time-based.
>
> Anyone for UTC only?