Subject: [lemonade] Future Delivery edit list

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 17 Feb 2006 08:40:50 -0600

I took an action item in London to post a -04 "final" version of the future delivery draft.  I have mined my email logs and found only the below message from Randy commenting on the BNF.

If there issues others, please shout now.

Randy suggests a clean-up to the BNF, but also suggests a esthetic preference for an alternate syntax.  Can I get a response from those folks who care as to which they prefer?  Based on the responses, I will pick one.  

a) HOLD=for;future-release-interval  and HOLD=until;future-release-date-time

- or -

b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Randall Gellens
Sent: Monday, November 07, 2005 7:20 PM
To: [email-masked]
Subject: Re: [lemonade] Question 2: how to change the extension
framework

Sorry about replying to an old thread.  Now that -03 has been 
published and went with the (IMHO) uglier syntax, the ABNF for it 
looks odd:

       Using ABNF [n2], the syntax of this parameter is as follows:

          future-release-interval = future-release-integer

          future-release-date-time = Internet-style-date-time-UTC

          hold-type = "for" / "until"

          hold-info = future-release-interval / future-release-date-time

          hold-param = "HOLD=" (("for;" future-release-interval) /
                                ("until;" future-release-date-time))

       The absence of this parameter on the MAIL command does not imply a
       default value for this parameter.

       NOTE:  The ABNF for hold-param contains expanded alternatives
       because of a deficiency in ABNF;  there is no way to indicate
      described in the text.  If we could, then the resulting ABNF for
       hold-param would be:

       hold-param = "HOLD=" hold-type ";" hold-info

It looks to me like the wording in the NOTE is missing a line.

But how about making the ABNF:

	hold-param	=	"HOLD=" hold-for / hold-until
	hold-for		= 	"for;" future-release-interval
	hold-until		=	"until;" future-release-date-time
	future-release-interval = future-release-integer
	future-release-date-time = Internet-style-date-time-UTC

This would cleanly show that you can use one form or the other.

Although I still think using "HOLD-FOR" and "HOLD-UNTIL" followed 
immediately by the value would be cleaner than using "HOLD" and then 
having an extra hold-type and semicolon before the value.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare

_______________________________________________
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: Antony Bowesman <[email-masked]>
Date: Fri, 17 Feb 2006 16:58:15 +0200

Vaudreuil, Greg M (Greg) wrote:
> 
> Randy suggests a clean-up to the BNF, but also suggests a esthetic preference
> for an alternate syntax.  Can I get a response from those folks who care as
> to which they prefer?  Based on the responses, I will pick one.
> 

I agree with Randy about b; it's cleaner with marginally less parsing needed. 
hold-type or hold-param does not allow extensions, so doesn't add value.

Antony

> 
> Greg V.
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Randall Gellens Sent: Monday,
> November 07, 2005 7:20 PM To: [email-masked] Subject: Re: [lemonade]
> Question 2: how to change the extension framework
> 
> 
> Sorry about replying to an old thread.  Now that -03 has been published and
> went with the (IMHO) uglier syntax, the ABNF for it looks odd:
> 
> hold-param = "HOLD=" (("for;" future-release-interval) / ("until;"
> future-release-date-time))
> 
> The absence of this parameter on the MAIL command does not imply a default
> value for this parameter.
> 
> NOTE:  The ABNF for hold-param contains expanded alternatives because of a
> deficiency in ABNF;  there is no way to indicate described in the text.  If
> we could, then the resulting ABNF for hold-param would be:
> 
> hold-param	=	"HOLD=" hold-for / hold-until hold-for		= 	"for;"
> future-release-interval hold-until		=	"until;" future-release-date-time 
> future-release-interval = future-release-integer future-release-date-time =
> Internet-style-date-time-UTC
> 
> Although I still think using "HOLD-FOR" and "HOLD-UNTIL" followed immediately
> by the value would be cleaner than using "HOLD" and then having an extra
> hold-type and semicolon before the value.

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Fri, 17 Feb 2006 10:54:49 -0800 (Pacific Standard Time)

On 2006-02-17/08:40 [-0600], [email-masked] [Vaudreuil, Greg M (Greg)] wrote:

> Randy suggests a clean-up to the BNF, but also suggests a esthetic 
> preference for an alternate syntax.  Can I get a response from those 
> folks who care as to which they prefer?  Based on the responses, I 
> will pick one.
> 

'b' is a cleaner syntax.

Anil

> having an extra hold-type and semicolon before the value.

_______________
Anil SRIVASTAVA
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Fri, 17 Feb 2006 11:16:16 -0800 (PST)

>> b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time

Unless it is intended that there be expansion space for other "hold" 
options, (b) is preferable to (a).

I believe that it is worth the exercise to consider, and to reject 
explicitly, the possibility of other "hold" options.  In other words, we 
should attempt the exercise of coming up with other possible "hold" 
options, and satisfy ourselves that they are undesirable and/or useless.

That way, we will also have the transcript of that discussion in the list 
archives, so that years from now when we are second-guessed, we can refer 
back to the discussion.

I personally believe that other "hold" options will turn out to be 
undesirable and/or useless.

-- 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: Dave Cridland <[email-masked]>
Date: Fri, 17 Feb 2006 20:40:51 +0000

On Fri Feb 17 19:16:16 2006, Mark Crispin wrote:
> Unless it is intended that there be expansion space for other 
> "hold" options, (b) is preferable to (a).
> 
> explicitly, the possibility of other "hold" options.  In other 
> words, we should attempt the exercise of coming up with other 
> possible "hold" options, and satisfy ourselves that they are 
Well, this sounds like an entertaining diversion. :-)

Both existing hold functions are, at their core, "Hold until a 
specific time", although they vary in how that time is specified.

The only other family I can think of is a "Hold until an event". 
There needs to be some corresponding mechanism to indicate that the 
event has happened, so this is really "Hold until explicit release", 
and the most generic version of this would use further ESMTP in some 
future session to "release" the message.

I can implement this now as a BURL based send, but that might lose 
the envelope, and does require a certain degree of infrastructure 
(which Lemonade mandates, but still). 
Alternately, I can implement by using CHECKPOINT, and sending by 
simply terminating the message at a later date, but the use of 
CHECKPOINT with BURL/BDAT is undefined, as far as I know. Note that 
*with* CHECKPOINT, we can also easily build any specific "Release 
this message when X happens", by supplying the most likely observing 
server of event X with the TRANSID to release (by using BDAT 0 LAST, 
of course).

Moreover, CHECKPOINT in a Lemonade setting would appear to be a 
sensible avenue to explore further anyway - I implemented it 
server-side a while ago, but I've not yet done the client side.

In any case, it would seem that further extending future delivery 
hold options to encompass "hold until an event" would be the wrong 
way of achieving that goal - not only would it mean much more work, 
but it'd yield fewer side-benefits.

A time-based release criteria is a specialization of a generic event 
based release criteria, and it happens that since there is no 
"internet cron", this does need extra hooks in order to support it - 
others do not, or if they do, submission is not the place to put the 
hooks.

That seems to support Mark's argument that we're unlikely to do any 
further HOLD=xxx; beyond what we have.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw