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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 24 Aug 2005 13:17:29 -0500

Mark,

I have always expected that an implementation of future delivery would convert the interval until a locally meaningful date-time upon receipt.  This would happen on the MTA that supports the future delivery servies.  We received several comments that reinforce in my mind that relying upon the client to know what time it is now, what timezone it is in, and to make sure the SMTP-Submit server agree's with the client are more complex than needed.  For example, how long till deployed clients figure out that our US congress has just changed daylight savings time rules?  And recall that states and municipalities may opt-out of such arrangements. 

Recall also the text in the SMTP submission document that one expected fix-up a submission server may be expected to perform is to insert a valid timestamp.

I figure a client can know what "send in 14 hours" means with little error, even in the face of mis-configuration.  A server can reliably know what "release in 14 hours" means.  Expecting a client to know UTC time, or worse, it's current offset from UTC at the moment is much riskier.

The boundary condition here is that if the relative time changes during the interval, the release time might be different than the user expected based on a simple UI.  But to fix it we need to know who's time change should be respected?  If daylight savings goes into effect where the server is located, it may not be in effect where the client is. They may both change in opposite directions if you are using a submission server on the other side of the equator.  The only way to do this perfectly right is to have the client declare the time-zone it wants to be using and the servers to know all possible time-zones and municipal exceptions so the transitions can be handled correctly.   Too much complexity.

Leave it to the client to know it's own time zones.... it can add an hour if it knows the "send it in a week" extends past the start of locally defined daylight savings.  

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mark Crispin
Sent: Wednesday, August 24, 2005 1:55 PM
To: [email-masked]
Subject: Re: [lemonade] I-D
ACTION:draft-ietf-lemonade-futuredelivery-02.txt

I should have commented on this before.  Sorry.

The current proposal only has a hold interval.

I request that it also be allowed to have a date-time in the AFTER= field. 
This could be done with something like the following syntax:
 	"AFTER=" ("+" interval) / date-time

The date-time must either include the zone or be in UTC.

Another issue has to do with the interpretation of hold interval.  The 
proposal suggests that the release time is calculated by adding the hold 
interval to the current time.  I'm not certain that this is correct; 
consider the effect of a time adjustment.

Also, what if the system is rebooted during the hold interval?  How does 
the MTA holding the message really know if the hold interval has passed or 
not?

Put another way, my argument goes like this:

If the intent is to hold until time T that is 14 hours in the future, it 
is better to specify "hold until time T" than "hold 14 hours".

If the intent is to hold 14 hours, regardless of what the system clock 
says, then it is wrong to calculate a release time based upon the current 
time and the hold interval.

It is probably quite a bit more difficult to implement "hold for 14 hours" 
than it is to implement "hold until time T".

Consequently, I would go as far as to advocate that "hold until time T" 
should be the only feature, and "hold for such-and-such interval" be a 
user interface.  However, I'm not dogmatic on this; I'll sign off on a 
feature that offers both as long as it's understand that some (many? 
most?) implementors will implement "hold for such-and-such interval" as 
"hold until time T calculated as now plus the interval."

One bit of good news is that I could actually implement this in one of my 
SMTP servers immediately; the associated MTA already has the capability 
(and has for 25 years!) but there was no way to communicate it from SMTP 
to the MTA.  Of course, we are talking about the TOPS-20 SMTP server and 
MTA here... :-)

On a slightly more serious note, given that I'd have an SMTP server and 
MTA to test this with immediately, I'll also implement it in the UW IMAP 
toolkit c-client library right away.  So there's hope of seeing the 
capability in Pine sooner rather than later.

-- Mark --

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

_______________________________________________
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: Wed, 24 Aug 2005 11:56:50 -0700 (PDT)

I respectfully disagree, especially given that your position has the 
effect of "force everybody to use interval" whereas my position is "once 
we allow date-time, I don't think anyone will use interval; but I won't 
insist upon removing interval as long as I can use date-time."

Let's separate the two issues:

First, can you come up with ANY HARM caused by allowing date-time?  If it 
does not cause any harm, and clients that don't want to use date-time can 
ignore it, why not allow it?

Second, as to whether date-time or interval is better; I'm willing to 
compromise on allowing both, since fighting about this question will just 
waste time and cause us to pull hair unnecessarily.

I think that events will prove that date-time is better; but I see no 
great harm to allowing interval as long as it's understood that at least 
some servers will implement interval as date-time = now+interval.  It 
doesn't matter who's right and who's wrong; if allowing both is harmless 
and we allow both, nobody's hurt.

On Wed, 24 Aug 2005, Vaudreuil, Greg M (Greg) wrote:
> I have always expected that an implementation of future delivery would 
> convert the interval until a locally meaningful date-time upon receipt. 
> This would happen on the MTA that supports the future delivery servies. 
> We received several comments that reinforce in my mind that relying upon 
> the client to know what time it is now, what timezone it is in, and to 
> make sure the SMTP-Submit server agree's with the client are more 
> complex than needed.  For example, how long till deployed clients figure 
> out that our US congress has just changed daylight savings time rules? 
> And recall that states and municipalities may opt-out of such 
> arrangements.

This is *precisely* the reason why I believe that it is important to offer 
a facility to send a date-time (with timezone) instead of an interval.

I think that many (most?) human users will queue with a particular time in 
mind.  At least I do.  I always set appointments based upon a time, not an 
interval in the future.

As matters stand now, the client must calculate the delta between now and 
that time in order to get the interval, send the interval, and then the 
server must add the interval to now to get the delivery time.

If the client's date-time is set wrong (a not-infrequent occurance with 
some mobile devices), then it will calculate an incorrect interval.  Not 
all cell phone providers set an accurate network time; I once saw a 70 
minute error from a rural provider in Canada (no, not a summer time error; 
it was 70 minutes late and it was summer).

More to the point; I tell my client "8PM Pacific time".  Either it passes 
that instruction to the server without alteration, or it calculates "in 14 
hours" based upon its knowledge that the time now is 6AM Pacific time. 
But if the time now is wrong, then that calculation was wrong.

> I figure a client can know what "send in 14 hours" means with little 
> error, even in the face of mis-configuration.

But how does the client come up with "in 14 hours"?  Aren't you assuming 
that the human user will say "in 14 hours" rather than "8PM Pacific Time"?

You're contradicting yourself.  First you say that a client can't know its 
time, then later you say "leave it to the client to know its local 
timezone".

> A server can reliably 
> know what "release in 14 hours" means.

This is only true if the server has a real-time clock that runs unimpeded 
for the entire period.  An uptime clock will get reset by a reload, and a 
time-of-day clock is subject to change.

I'll wager that most server implementations will simply add the interval 
to the current time-of-day clock, and not concern themselves as to whether 
or not the actual interval occurs.

> Expecting a client to know UTC 
> time, or worse, it's current offset from UTC at the moment is much 
> riskier.

I'm not necessarily requiring a client to know UTC or any time at all.

I'm just asking that the human user knows what time he wants it delivered, 
and has some notion of the intended time zone.  Most people understand 
"8PM US Pacific time", "14:30 London time", "0900 Tokyo time", etc.

If you allow a date-time request (with zone!) then the only entity that 
has to figure it out is the server, and the result of the calculation is 
the release time.

-- Mark --

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Aug 2005 22:13:59 +0200

Hi Mark,

let me try to list the various possible differences, and the effect of 
the interval syntax on each, assuming "natural" server and client 
implementations. I'll list the more common situation first.

In all cases, the user at 10:15 instructs the client that a message 
should be delivered at 14:00.

1. Client's clock is broken. In that case, interval syntax means that 
the message is delivered when the client's clock shows 14:00, as 
opposed to the server's clock.

2. Client is not in the same timezone as server. As case 1.

3. A leap second is introduced. Message may delivered a second earlier 
than intended.

4. The server's timezone changes, and the client is in a different 
timezone. Message is delivered at the right time.

5. Timezone changes unexpectedly, and the server and client are in the 
same locale. Message may be delivered an hour earlier or later than 
intended.

6. The server is moved to a different locale (new colo, perhaps). 
Message may be delivered earlier or later than intended (also the case 
with date-time).

As far as I can see, interval wins a day-to-day case (2), the other 
day-to-day case is a draw, the leap second case isn't big enough to 
care about, and the obscure cases are a draw. To my mind, this says 
"use interval and don't clutter the protocol with date-time".

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 24 Aug 2005 13:36:45 -0700 (Pacific Daylight Time)

On Wed, 24 Aug 2005, Arnt Gulbrandsen wrote:
> In all cases, the user at 10:15 instructs the client that a message should be 
> delivered at 14:00.

Let's add that this is 14:00 tommorrow.

> 1. Client's clock is broken. In that case, interval syntax means that the 
> message is delivered when the client's clock shows 14:00, as opposed to the 
> server's clock.

Not quite.

Interval syntax means that the message is delivered when the server's 
clock reaches the time that the server calculated by adding the interval 
to the server's clock when it got the request.

That may not necessarily be the same as "when the client's clock shows 
14:00."

Date-time syntax means that the message is delivered when the server's 
clock reaches 14:00, adjusted as necessary by a differential between the 
timezone requested by the client (not necessarily the same as the timezone 
set at the client!) and the server's timezone.

Date-time wins here.

> 2. Client is not in the same timezone as server. As case 1.

It is "as case 1", but not for the reasons you thought.

> 3. A leap second is introduced. Message may delivered a second earlier than 
> intended.

We agree that this is not an important case.

> 4. The server's timezone changes, and the client is in a different timezone. 
> Message is delivered at the right time.

Not necessarily.  You are presuming that the client correctly calculated 
the interval.  Suppose it is 2006, my mobile device didn't get updated for 
the change in US law, so it calculated an interval that is an hour off.

Now, if my mobile device sent the time, the server (with updated software) 
would do the right thing.

Date-time wins.

> 5. Timezone changes unexpectedly, and the server and client are in the same 
> locale. Message may be delivered an hour earlier or later than intended.

Same as 5.  The important thing is the time when the event occurs.  If we 
set up a meeting time in the future, we're not doing it according to the 
offset from UTC that we honor when we make the meeting.  We're doing it 
according to the offset at the time of the meeting.

Date-time wins.

> 6. The server is moved to a different locale (new colo, perhaps). Message may 
> be delivered earlier or later than intended (also the case with date-time).

This is a draw with interval and date-time.  Remember, date-time includes 
the timezone in the request.

To my mind, interval wins in none of the above cases and at best is a 
draw.

As for the "protocol complexity" issue, put me down as an MTA author who 
feels that it's a non-issue:
  . it only affects MTAs; MUAs can ignore the feature (interval or
    date-time) that they don't care to use.
  . MTAs already have to support date-time

The more interesting problem is how to represent "14:00 US Pacific time" 
as opposed to "14:00 -0800" and "14:00 -0700"; because we really want "US 
Pacific time" and not a UTC offset.  Fortunately, it appears that the 
calendaring folk are already grabbing this bull by the horns.

-- Mark --

---

From: Antony Bowesman <[email-masked]>
Date: Thu, 25 Aug 2005 08:34:39 +0300

Hi Arnt,

Greg limits his terminology to "release", but both you and Mark talk about 
"delivery".  My reading of the first draft also led me to believe it can be used 
for specifying delivery, but Greg has said this is not about delivery, simply 
release.  If that's the case, then delta times are sufficient and there's no 
benefit to having date/time.

The spec is somewhat schizophrenic in that it mentions both "release" and 
"delivery at".  The introduction goes on to imply that it can be used to 
introduce messages with knowledge of the recipients' time zones.  All of the 3 
examples given would require knowledge of the recipients' time zones.  If I want 
to remind myself of an event, I have to know what zone I will be when the event 
is to occur.  If I want to send a start of day announcement to recipients in 
London, Helsinki and Tokyo I have to know their time zones, although this 
clearly cannot be achieved in a single message by this specification.

What are the the real use cases for release_at, if delivery_at is not taken into 
account.  The use cases for delivery at are much easier to see than release at 
and some of these are identified in the intro.

Think about how a client UI would expose a release at feature without 
introducing any discussion of delivery and server and recipient time zones 
thereby accidentally leading the user to believe that the recipient will receive 
the message at the appointed time.

If it's only about message release, then it should not be called 
"futuredelivery" and should become perhaps "deferuntil" and not promise the 
features outlined in the intro.

I would favour an attempt to enable the features outlined in the intro, but am 
not sure how this could be achieved given the multi time zone example.

Certainly, the use cases in the intro are valid if delivery is considered 
(discounting provider, network hops and latency in delivery), but if I were to 
send birthday greetings to the "australian cousin", it's more intuitive for the 
client to send 8am UTC+1100, or UTC+1000 if it's in the australian winter than 
to calculate some interval between a possibly correct client time and when I 
want the cousin to receive the greetings.

vCard supports time zone attributes as well as supporting time zones in 
attributes such as BDAY, so there's no reason why a client implementation 
shouldn't make use of this data to implement support for future delivery.

Antony

> the message is delivered when the client's clock shows 14:00, as opposed 
> to the server's clock.
> 
> day-to-day case is a draw, the leap second case isn't big enough to care 
> about, and the obscure cases are a draw. To my mind, this says "use 
> interval and don't clutter the protocol with date-time".
> 
> Arnt
>

---

From: Mark Crispin <[email-masked]>
Date: Wed, 24 Aug 2005 23:02:09 -0700 (PDT)

For what it's worth, I agree with all of Antony Bowesman's observations. 
I thank him for stating what I felt as a gut reaction but was unable to 
express in a coherant fashion.

I especially agree with his observations about "release" vs. "delivery 
at".  If this specification is intended to be solely involved with 
release, then indeed delta times are sufficient.

My confusion does indeed originate with the fact that the current 
specification makes use of the term "delivery" and has examples of 
delivery, not release.  If the intent is to be solely "release", then 
references to "delivery" need to be purged and the examples replaced.

I am indeed thinking about such facilities as birthday greetings to 
friends in Japan (who, because of the international date line, will get 
the message delivered nearly a day earlier than what would be their 
birthday in Seattle), scheduled meeting reminders (cheap and dirty 
calendaring), etc.

I hadn't thought about per-recipient delivery days but I agree with Antony 
that the lack of this is a deficiency that should be addressed.  [And an 
"oops, sigh, oh well" on my part, since the delayed delivery feature in 
the TOPS-20 MTA is per-message, as in the current specification, not 
per-recipient, as is probably needed.]

-- Mark --

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 25 Aug 2005 12:24:20 +0200

Hm, I see the disconnect now. I always read the draft as solving the 
simple issue that might be described as "deferuntil", the one that 
gives 80% result for 20% effort, and didn't really understand that 
people might read the draft differently.

The draft enables me to send mail in three hours or tomorrow morning, at 
a time when I know I won't be at the keyboard. Useful, say I. 
Personally I've wanted that often.

I don't think the draft enables me to send mail at 2006-03-14 14:00, 
because it demands a fixed list of recipients, content and delivery 
date right now. If a meeting is planned at 2006-03-15 14:00, there's 
every chance that the agenda, list of attendees, venue, date or time is 
changed before 2006-03-14, and the draft doesn't give me any way to 
recall or change the meeting announcement. Possible time skew seems 
tiny compared to that.

I'm not sure whether a change of name is necessary. A change of emphasis 
and/or examples sounds good.

(I also had a think about timezone, and IMNSHO it's not reasonable that 
SMTP server administrators should have to keep updated time zone 
information for all over the world. People just aren't that diligent. 
Wasn't there some US change this autumn? A lot of administrators 
outside the US won't even hear about that change, far less regard it as 
a valid reason to upgrade their production mail servers.)

Arnt

---

From: Tony Hansen <[email-masked]>
Date: Thu, 25 Aug 2005 08:56:00 -0400

Dealing with time zones is definitely non-trivial. And if your GUI wants
to present this feature as "deliver this message after XXX in YYY", it
must be paid attention to.

The US change won't occur until 2007. Fortunately, the algorithms don't
change that often.

The issue with time zone information is also being discussed in calsify.
	Tony Hansen
	[email-masked]

Arnt Gulbrandsen wrote:
> Wasn't there some US change this autumn? A lot of administrators outside
> the US won't even hear about that change, far less regard it as a valid
> reason to upgrade their production mail servers.)