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

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Sep 2005 14:33:25 -0700

At 8:34 AM +0300 8/25/05, Antony Bowesman wrote:

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

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.  The draft extends this so that the server does the 
holding.

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

The obvious way to do it would be to pass the message on to the final 
recipient with the future delivery interval in the header, much as 
deliver-by does.  However, unlike deliver-by, doing so would impose 
storage and queuing requirements on the final delivery server don't 
seem to be appropriate, not to mention introducing extra security 
risks since the final delivery server would not have a relationship 
with the sender.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The significant problems that we face today cannot be solved at the
same level of thinking that created them.         --Albert Einstein

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Sep 2005 14:40:41 -0700 (PDT)

On Thu, 15 Sep 2005, Randall Gellens wrote:
> [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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 15 Sep 2005 23:48:16 +0200

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

Mark Crispin answers:
> Not clear to me. [...]

Randy, could you ask eudora support whether this has in fact been a 
problem for Eudora users, and if so, how big?

The best is the enemy of the good/the good is the enemy of the best.

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Sep 2005 16:36:30 -0700

> problem for Eudora users, and if so, how big?

I'm told it has not been a problem.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.                                           --Mark Twain

---

From: Antony Bowesman <[email-masked]>
Date: Fri, 16 Sep 2005 13:20:35 +0300

Randall Gellens wrote:

 >>  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.
 > 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.  The draft extends 
this so that the server does the holding.

True, it's easy to understand in the queuing context.  However, I understand 
this to be useful when you have no connection and want items to be queued until 
the next time you have a connection.

Once server side holding comes into effect, Eudora's send or or after would need 
to explain that connection is actually now needed to send mails queued for later 
delivery.

What is the thought process of the average user with a permanent connection when 
presented with the "on or after" option.  I expect all involved here understand 
how mail gets delivered, but when joe public has the expectation that shortly 
after hitting the send button, the recipient will get the mail, its difficult to 
see the value of pure server side "release at" without users thinking it equates 
to some delivery time.

My conclusion is that the SMTP keyword of FUTUREDELIVERY implies something the 
draft does not attempt to provide, which in turn may lead to confusion by 
implementers.  What about FUTURESUBMISSION?

Antony

---

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

On Fri, 16 Sep 2005, Antony Bowesman wrote:
> My conclusion is that the SMTP keyword of FUTUREDELIVERY implies something 
> the draft does not attempt to provide, which in turn may lead to confusion by 

I (strongly) agree with this observation.

-- Mark --

http://panda.com/mrc

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Sep 2005 12:15:07 -0700

At 1:20 PM +0300 9/16/05, Antony Bowesman wrote:

>> easy to understand: the client holds the message until at least 
>> the specified date and time.  The draft extends this so that the 
>> server does the holding.
>
>
>  True, it's easy to understand in the queuing context.  However, I 
> understand this to be useful when you have no connection and want 
> items to be queued until the next time you have a connection.

No, that's just regular queueing.  The "on or after" is specifically 
for deliberately delayed mail.  I've used it as such, and yesterday I 
chatted with a few others who told me they also have done so.

>
>  Once server side holding comes into effect, Eudora's send or or 
> after would need to explain that connection is actually now needed 
> to send mails queued for later delivery.
>
>  What is the thought process of the average user with a permanent 
> connection when presented with the "on or after" option.

I believe it is "I want this mail delivered after 9:00 AM tomorrow".

>    I expect all involved here understand how mail gets delivered, 
> but when joe public has the expectation that shortly after hitting 
> the send button, the recipient will get the mail, its difficult to 
> see the value of pure server side "release at" without users 
> thinking it equates to some delivery time.

Users may indeed have such an expectation; I do not know.

>
>  My conclusion is that the SMTP keyword of FUTUREDELIVERY implies 
> something the draft does not attempt to provide, which in turn may 
> lead to confusion by implementers.  What about FUTURESUBMISSION?

Protocol keyword does not need to be changed to affect user expectations.

-------------- Randomly-selected tag: ---------------
The reliability of machinery is inversely proportional to the
number and significance of any persons watching it.

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 16 Sep 2005 12:37:40 -0700

> Protocol keyword does not need to be changed to affect user expectations.

If the name is confusing, it should be changed, so that developers
aren't confused.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Sep 2005 13:38:44 -0700

>  If the name is confusing, it should be changed, so that developers

I'm just not sure that the current name is that confusing.  If people 
feel strongly that it is, we could use HOLD.  This has an advantage 
in that it is short, and doesn't imply hold-until (date-time) or 
hold-for (interval), thus allowing that issue to be separately 
resolved.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is hardly anything in the world that some one cannot make a
little worse, and sell a little cheaper.  --John Ruskin (1819-1900)

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 13:50:23 -0700 (Pacific Daylight Time)

On Fri, 16 Sep 2005, Randall Gellens wrote:
> I'm just not sure that the current name is that confusing.  If people feel 
> strongly that it is, we could use HOLD.  This has an advantage in that it is 
> short, and doesn't imply hold-until (date-time) or hold-for (interval), thus 
> allowing that issue to be separately resolved.

I think that HOLD is bad for the the reasons that you state; it leaves 
ambiguous whether it is date-time or interval.

I'm willing to sign off on HOLD-FOR:interval as something that will 
definitely go in (and thus can be declared "done"), and continue to 
advocate for HOLD-UNTIL:date-time as an additional feature.

Deal?

-- Mark --

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

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Sep 2005 16:21:45 -0700

> advocate for HOLD-UNTIL:date-time as an additional feature.

Sounds good to me, but then, I wasn't arguing for or against interval 
or date-time.  I think the protocol is simpler if we have one or the 
other; I don't actually care that much which one it is.  I think 
interval seems simpler (because of the client and server clocks being 
out of synch), but I don't have strong feelings either way and won't 
argue (much) either way.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Politics offers yesterday's answers to today's problems.
                                     --Marshall McLuhan

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 16:27:56 -0700 (Pacific Daylight Time)

On Fri, 16 Sep 2005, Randall Gellens wrote:
> I think the protocol is simpler if we have one or the other; I 
> don't actually care that much which one it is.  I think interval seems 
> simpler (because of the client and server clocks being out of synch), but I 
> don't have strong feelings either way and won't argue (much) either way.

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.

If the client has accurate time, then it doesn't matter what the protocol 
offers; it's easy enough to convert to the proper form.  The problem is if 
the client does not have accurate time.  Then it is difficult, if not 
impossible, to do one if the protocol forces you to do the other.

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Fri, 16 Sep 2005 16:36:07 -0700

At 4:27 PM -0700 9/16/05, Mark Crispin wrote:

>  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.
>
>  If the client has accurate time, then it doesn't matter what the 
> protocol offers; it's easy enough to convert to the proper form. 
> The problem is if the client does not have accurate time.  Then it 
> is difficult, if not impossible, to do one if the protocol forces 
> you to do the other.

But options mean a more complex protocol, and more work when we go to Draft.

I'd be happy going with one for now, with the ability to extend it 
later.  So your suggestion to do hold-for now, and hold-until as an 
option later sounds good.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter

---

From: Mark Crispin <[email-masked]>
Date: Fri, 16 Sep 2005 17:38:47 -0700 (Pacific Daylight Time)

> But options mean a more complex protocol, and more work when we go to Draft.

I find it unbelievable that a working group that created the IMAP CATENATE 
extension (which I agree, albeit reluctantly, is needed) would balk at 
something as minor as this.

> I'd be happy going with one for now, with the ability to extend it later.  So 
> your suggestion to do hold-for now, and hold-until as an option later sounds 
> good.

How do I instruct my mobile device to send a message for delivery after 
9AM Tokyo time when it does not know the correct current time and/or the 
timezone?  I'm roaming in Lower Slobbovia.

Note that I am cognizant of the fact that 9AM Tokyo time is midnight UTC, 
so it doesn't matter that neither my phone nor my server knows what 
"Tokyo" is.  I just need to delay it until midnight UTC.

-- Mark --