Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt

From: [email-masked]
Date: Wed, 17 Aug 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: SMTP Submission Service Extension for Future Delivery
	Author(s)	: G. White, G. Vaudreuil
	Filename	: draft-ietf-lemonade-futuredelivery-02.txt
	Pages		: 10
	Date		: 2005-8-17
	
This memo defines an extension to the SMTP submission protocol for
   client indication of a future-delivery time.  This extension permits
   a client to use server-based storage for a message that should be
   held in queue until an appointed time in the future.  This is useful
   for clients which do not have local storage or are otherwise unable
   to release a message for delivery at an appointed time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredelivery-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-futuredelivery-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-futuredelivery-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Wed, 24 Aug 2005 10:54:49 -0700 (PDT)

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.