Subject: [lemonade] date-time and delta time [was RE: I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt]

From: "Eric Burger" <[email-masked]>
Date: Fri, 16 Sep 2005 14:32:58 -0400

Let us not confuse the user interface with the protocol.  The good news
here is that either choice in the protocol, interval or date-time, can
support either choice in the client.

Since the specifications are isomorphic, I would first propose that we
chose one and only one specification for the protocol.  If one would
rather use a different representation in one's user interface, which is
great.

Note that if we do use date-time, I [as chair] would fully expect us to
use the RFC3339, Date and Time on the Internet: Timestamps, format.
RFC3339 dictates the use of UTC, which eliminates the whole issue of
time zones and standard time versus savings time IN THE PROTOCOL.

Some thing has to deal with time zones.  Either the client, the server,
or both can participate.

For example, if the protocol uses date-time, but the user interface uses
"Send after X hours", the user interface takes the local time, converts
it to UTC, adds X hours, and uses the result of that calculation as when
to release the message.  This, of course, presupposes the client's
concept of the current time in UTC is fairly close to the server's
concept of the current time in UTC.  It also means the client needs to
know the rules for converting local time to UTC.

If the protocol uses date-time, and the user interface uses "Send at
YY:ZZ", the user interface converts YY:ZZ (in local time) to UTC and
uses this result for the release request.  This, of course, presupposes
the client's concept of the current time in UTC is fairly close to the
server's concept of the current time in UTC.  It also means the client
needs to know the rules for converting local time to UTC.

If the protocol uses date-time, and the user interface uses "Deliver at
YY:ZZ in the recipient's time zone", the user interface converts YY:ZZ
to UTC and uses this result for the release request.  This, of course,
presupposes the client's concept of the current time in UTC is fairly
close to the server's concept of the current time in UTC.  It also means
the client needs to know the rules for converting remote time to UTC.

If the protocol uses delta time, and the user interface uses "Send after
X hours", the user interface simply requests the server to release the
message after X hours.  Note that there is no dependency on the client
and server clocks being in synchronization.

If the protocol uses delta time, but the user interface uses "Send at
YY:ZZ", the user interface calculates the interval between current time
and YY:ZZ, and uses the result for the release request.  Note that there
is no dependency on the client and server clocks being in
synchronization.

If the protocol uses delta time, but the user interface uses "Deliver at
YY:ZZ in the recipient's time zone", the user interface converts YY:ZZ
to UTC, converts local time to UTC, calculates the delta time, and uses
this result for the release request.  Note that there is no dependency
on the client and server clocks being in synchronization.  It also means
the client needs to know the rules for converting remote time to UTC.

At first glance, using delta time has a bunch of benefits over
date-time.  The largest one is there is no need for coordinating clocks.
If the local clock is wrong, that is "too bad".  Local time is the
responsibility of the local user.  If the local time setting is wrong,
one would expect the user to figure that out, as more than just their
mail will be wrong.  Likewise, if the user travels, but does not change
their client clock, as I do on my PC, *I* know what time zone my PC
thinks it is in.  Likewise, if the user travels, and does change their
client clock, but not the time zone, as I used to do on my Palm, *I*
know the time zone is wrong but the time is right.  Finally, if the user
travels, and changes their time zone, as I do on my Treo, *I* know the
time zone and time is correct.  How can I do that on my Treo?  Because
the latest Palm applications store everything in UTC!

The big drawback of using delta time occurs if the user interface uses
date-time.  In this case, something needs to know how to convert the
user's date-time input into the local time.  This is a minor problem if
the date-time the user enters spans a savings / standard time boundary.
In this case, the client needs to know the local rules for the local
time zone.  I would offer that if the client chooses to offer date-time,
then it will offer proper time zone conversion.

An alternative is for the client to send date-time to the submission
server, and have the submission server convert from date-time to delta
time.  This moves the burden of updating time zone rules from the
order(s) of magnitude more clients than submission servers.  However,
this adds the burden of the submission server knowing the time zone of
the client, and requires the coordination of the client and submission
server clocks.

<chair-hat-off>
Thus I would offer the protocol use delta time, and possibly have a note
in the text on the issues of using date-time in the user interface.
</chair-hat-off>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Crispin
Sent: Thursday, September 15, 2005 5:41 PM
To: Randall Gellens
Cc: [email-masked]; [email-masked]
Subject: Re: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.t xt

On Thu, 15 Sep 2005, Randall Gellens wrote:
> Eudora, for one, supports an option to "Send message on or after 
> [date-time]".  It does not mention delivery, nor server nor recipient
time 
> zone.  I've always thought the feature was fairly easy to understand:
the 
> client holds the message until at least the specified date and time.

Not clear to me.  If I am at an airport in Japan, using my server in 
Seattle and send a message with such a specification to someone in 
Scotland, whose date-time is used?  Does it matter if I remembered to
set 
my PC's timezone to Japan time, or if I did the obvious mistake of 
changing the clock instead?

Please explain why any of these is unambiguously preferable to the other

two such that it does not have to be documented which of the three 
possibilities is used.  I am unable to come up with such an explanation 
for any of the three.

-- 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: Fri, 16 Sep 2005 12:02:39 -0700 (PDT)

> time zones and standard time versus savings time IN THE PROTOCOL.

Agreed.

> in the text on the issues of using date-time in the user interface.

Can someone please explain to me the harm in having the protocol accept 
BOTH delta time *AND* RFC3339 time?

I doubt that this is a significant server implementation burden.

Clients can choose which they want to use, based upon their own desires 
and needs.  The client has perfect freedom to choose what it wants.

I don't see the choice as being between delta time and date-time, with 
partisans on both sides.  I see the choice as being between delta time 
ONLY (thus offending the date-time partisans) and doing BOTH.

Either I'm stupid, or naive, but I simply cannot grasp what is wrong with 
doing BOTH.

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 12:50:38 -0700

If the client knows accurate time, then it does not matter if the protocol 
offers date-time or delta time.  Either can be accurately derived from the 
other.

However, if the client does not have accurate time (and I know from 
first-hand experience that some CDMA and GSM networks do not transmit 
accurate time!), then the client will not get its intended effect if it 
must send a calculated value as opposed to its intended value.

This works *both* ways.

If the client's time is wrong, it is equally disasterous to use a 
calculated delta time (when a date-time was the intent) as it is to use a 
calculated date-time (when a delta time was the intent).

I believe that the implementation burden on the server to offer both is 
small, particularly if we require date-time to be RFC3339 UTC time.  With 
the protocol requiring UTC time, we wash our hands of the timezone issue. 
If the client and/or human user can't figure out what to do, we fall back 
to using delta time (which is what the other side of this issue says 
should be the only option).

If the mobile phone provider in [censored] gives my CDMA phone a known 
bogus time (78 minutes late the last time I was there), I should still be 
able to send a message with delivery delayed to a specific time in Tokyo, 
given that I (human user) know that Tokyo's timezone is +9.  I can 
subtract 9 from my intended Tokyo time easily enough.

But, to get my phone to calculate the right delta, I must have some source 
of accurate time independent of my phone, and must know that time's 
timezone.  I can then calculate the delta to my intended Tokyo.  If the 
phone's user interface requires entering in a date-time instead of a 
delta, I must then add that delta to the phone's (incorrect) time in order 
to get the (incorrect) time for delivery that I then enter in the phone so 
that the phone can calculate the delta.

Whew!

Of course, the above argument assumes that the phone microcoder will use 
both delta time and date-time as appropriate for the user's intentions. 
That may not be the case.

But I know that in my (non-phone) application, I would only use date-time, 
and being forced to send delta time would introduce a source of error.

I really want the choice.

Also, if Lemonade insists upon delta time only, then the keyword name must 
be changed so that it is not confused with an independent specification 
that will offer date-time.

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 20:53:55 -0700 (PDT)

On Fri, 16 Sep 2005, Chris Newman wrote:
> I believe the arguments against date-time only are compelling and I oppose 
> that position.

For what it's worth, I agree.  I don't think that anyone supports 
date-time only.

It occurs to me that for short delays (e.g. 2 or 3 digit minute values) 
delta time is unambiguously superior; and perhaps this is what the 
advocates of delta time only are thinking about.

I'm thinking about being able to use this facility for long delays (days, 
weeks, months).  Now, we're talking about 6+ digit minute values for delta 
time.

I think that maybe this is why there's a disconnect.  Unless we plan to 
impose a protocol maximum limit on the delay time, there's the potential 
of a user wanting to set long delays.

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 16 Sep 2005 21:25:38 +0200

Mark Crispin writes:
> Can someone please explain to me the harm in having the protocol 
> accept BOTH delta time *AND* RFC3339 time?

If you want the server to handle the client's and recipient's timezone, 
then the server has to know the local time for all locales, which in 
turn means that each server's timezone database must be updated 
whenever any locale anywhere in the world changes its rules. This is a 
new demand. (Personally speaking: In the eleven years that maintaining 
mail servers has been a (small) part of my job, I can't remember ever 
updating the timezone database on a production mail server.)

Then there are the general aguments. More options in the protocol means 
more regression testing for implementers. More options in the protocol 
means more i14y blues. Even if the price is low, it can be too high for 
the value provided.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 12:37:11 -0700

On Fri, 16 Sep 2005, Arnt Gulbrandsen wrote:
> If you want the server to handle the client's and recipient's timezone

The stipulation of RFC3339 time eliminates this consideration.  RFC3339 
time is UTC.

> Then there are the general aguments. More options in the protocol means more 
> regression testing for implementers. More options in the protocol means more 
> i14y blues. Even if the price is low, it can be too high for the value 
> provided.

date-time provides useful functionality at low cost.  Consider data that 
is embargoed for release until a particular time (e.g., for arbitrage), 
and the client is not certain of its time.

-- Mark --

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Sep 2005 20:10:18 -0700

Mark Crispin wrote on 9/16/05 12:02 -0700:
> partisans on both sides.  I see the choice as being between delta time ONLY
> (thus offending the date-time partisans) and doing BOTH.
>

I lean towards doing BOTH as the implementation cost on the server is not great 
and the client is then free to implement whichever is most convenient.

However, I would not oppose a rough consensus in favor of delta-time only.

I believe the arguments against date-time only are compelling and I oppose that 
position.

                - Chris

---

From: Antony Bowesman <[email-masked]>
Date: Mon, 19 Sep 2005 08:57:52 +0300

Mark Crispin wrote:
> I'm thinking about being able to use this facility for long delays 
> (days, weeks, months).  Now, we're talking about 6+ digit minute values 
> for delta time.

I agree.  The explicit setting of a 1 second delta time allowed for in the spec, 
seems an unusual use case, unless arrived at through a miscalculation of future 
time zones or local clock settings.

> of a user wanting to set long delays.

There is already a limitation: it's approximately 31.7 years :)

Antony

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 19 Sep 2005 09:44:49 +0200

Chris Newman writes:
> I lean towards doing BOTH as the implementation cost on the server is 
> not great and the client is then free to implement whichever is most 
> convenient.

Question.

As Mark later said, there probably is a difference in mindset. If you 
like delta, your use cases are short-term. If you like date-time, 
long-term. Made me think a little. So: Is it a good idea to provide a 
mechanism intended for long-term storage and eventual delivery without 
providing revocation?

I don't have a position. My use-cases are short-term, and anyway I'm 
neutral in general over whether IETF standards should 
support/discourage pointing guns at own extremities.

Arnt

---

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

On Mon, 19 Sep 2005, Arnt Gulbrandsen wrote:
> Is it a good idea to provide a mechanism intended for 
> long-term storage and eventual delivery without providing revocation?

One of the three mailsystems that had this feature had revocation, but 
only for messages that were still queued.

> I don't have a position. My use-cases are short-term, and anyway I'm neutral 
> in general over whether IETF standards should support/discourage pointing 
> guns at own extremities.

As any gun-nut will tell you, one of the four basic rules of gun safety is 
"never point a gun at anything you don't want to destroy."  :-)

However, IETF standards have rarely, if ever, succeeded in preventing 
people from shooting themselves.  Standards that try end up spending a lot 
of time arguing the issue.

-- Mark --

http://panda.com/mrc

---

From: Chris Newman <[email-masked]>
Date: Wed, 21 Sep 2005 11:05:23 -0700

Arnt Gulbrandsen wrote on 9/19/05 9:44 +0200:
> As Mark later said, there probably is a difference in mindset. If you like
> delta, your use cases are short-term. If you like date-time, long-term. Made
> me think a little. So: Is it a good idea to provide a mechanism intended for

I'd say we shouldn't introduce a long-term future submission mechanism unless 
we know how to build a revocation system in the future.  But I don't believe we 
should wait to build that system before advancing the future submission 
mechanism.  I see two possible architectures for revocation:

1. Piggy-back it on RFC 3885.

2. Have long-term queued messages actually land in a special IMAP "outbox" 
folder
   which is mostly read-only but permits delete/expunge.  This could use an
   annotation to store the SMTP envelope.

The former has the advantage that it creates no link between the MTA and store 
and places no restrictions on where the messages are queued.  But it pushes the 
complexity into the client and requires standards work.  The latter has the 
advantage that it can be implemented without changing any standards.  But it 
would require some implementation linkage between the submit and IMAP servers 
which may not be desirable.

I can't say which is the right solution -- perhaps they're sufficiently 
different that both make sense.  But because there are two reasonable solutions 
for revocation, I don't consider see a reason to block the future submission 
extension waiting for the technical details.

                - Chris

---

From: Dave Cridland <[email-masked]>
Date: Wed, 21 Sep 2005 19:28:25 +0100

On Wed Sep 21 05:05:23 2005, Chris Newman wrote:
> I'd say we shouldn't introduce a long-term future submission 
> mechanism unless we know how to build a revocation system in the 
> future.  But I don't believe we should wait to build that system 
> before advancing the future submission mechanism.  I see two 
> possible architectures for revocation:
> 
> 2. Have long-term queued messages actually land in a special IMAP 
> "outbox" folder

You could also advance CHECKPOINT (RFC1845) off Experimental, and add 
message revocation to that, so you'd revoke a TRANSID.

Dave.

---

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

On Wed, 21 Sep 2005, Chris Newman wrote:
> I see two possible architectures for revocation:
>  folder which is mostly read-only but permits delete/expunge.  This
>  could use an annotation to store the SMTP envelope.

I think that (1) is preferable to (2), because of the linkage between 
submission and store implied by (2).

(2) also skates perilously close to the thin ice of submission in IMAP. 
Architecturally, I believe that the overall email infrastructure should be 
designed do that any component can be altered or replaced without 
impacting any other.  This isn't completely doable (e.g., there will 
there will always linkages involving RFC2822/MIME).  But it's a good goal 
to strive for anyway.

I also have a big problem with the term "revocation".  This implies the 
capability to revoke a message which has already been delivered, something 
that we have historically refused to accept as either doable or desirable.

I prefer the term "cancellation".  We are NOT revoking a sent message. 
We are cancelling a request to send a message at a future time.

We can cancel what has not yet been done.  We can not (I would argue 
should not) revoke what has already been done.

This creates a separate concept of "submitting a request" vs. "sending a 
message."  Actually, the concept was created by adding future-time 
submission, but it didn't become apparent until cancellation is 
considered.  Anyway, I think that this is a good thing.

Also, I believe that we should have the option to cancel short-term and/or 
delta-time requests as well as long-term and/or date-time requests.  It 
shouldn't matter how it was submitted, nor how far in the future the 
request will be released.  It should only matter that the request has not 
been released yet.

-- Mark --

http://panda.com/mrc

---

From: Antony Bowesman <[email-masked]>
Date: Mon, 19 Sep 2005 08:47:37 +0300

> I doubt that this is a significant server implementation burden.

Agreed [strongly].

Antony