Subject: RE: [lemonade] Question 2: how to change the extension framework

From: "Eric Burger" <[email-masked]>
Date: Tue, 18 Oct 2005 04:05:36 -0400

The ugly duckling in EHLO Option 1 is what to do if the two
specifications do NOT result in the same future time.  I know this is
hard to believe, but some server implementations have bugs, and others
may wish to exploit client implementation errors by sending bad protocol
elements. [Randy - keep your flags to yourself :-]

The problem is, I don't have text to offer.  I was inclined to say, "The
server uses Delta Time to indicate the maximum hold Time, and if the
client wants to use date-time, it has to convert the delta time to
date-time."  However, that assumes the client has all of the local and
(if you believe the I'm a U.S. user traveling in the U.K. sending a
message to Japan and I want to specify the release time in Japan) global
time zone rules.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg White
Sent: Sunday, October 16, 2005 11:43 PM
To: [email-masked]
Subject: [lemonade] Question 2: how to change the extension framework

Based on reading the list...

Question 2:

The list has decided that the framework of the extension needs to be as
follows:

   1)  The submission server needs to be able to handle requests for
future
release in BOTH of the following ways:  
      a)  hold until a given time interval elapses, then release message
      b)  hold until a given date-time occurs, then release message.

   2)  The client can choose EITHER 1a) OR 1b), as his future release
method
when submitting a future release request.

In the following discussions, I am not proposing actual syntax for the
draft, just extension framework options...

Here are two options that stand out to me for replacing the AFTER
parameter:

option 1:  introducing two parameters "HOLDFOR=time_interval" and
"HOLDUNTIL=RFC3339_date_time", with appropriate text (and ABNF?)
indicating
that the client MUST use ONLY ONE of the parameters on the MAIL command

option 2:  introducing one parameter, HOLD, which has two parm values,
hold-type and hold-info.  The parameter usage would then look like this:
"HOLD=for;time_interval" or "HOLD=until;RFC3339_date_time".  I got the
idea
from the ORCPT parm of the DSN extension which is, basically,
"ORCPT=addr-spec;addr"

My preference is option 2, because "my gut feeling" is that the
associated
draft text and ABNF would be cleaner, and aligns with other extension
work,
but I will defer to the mail experts.

Here are some options that stand out to me for fixing the EHLO keyword:

I am making the assumption that, since we now offer hold-for and
hold-until
options, we need to advertise the max-hold-for-value (time interval) and
max-hold-until-value (RFC3339 date-time) in the EHLO response, and need
to
ensure that the two values essentially indicate the same
point-in-future-time...

option 1:  FUTURERELEASE FOR;max-hold-for-value
UNTIL;max-hold-until-value

option 2:  assuming that there is no restriction on the number of
keywords
advertised by a single extension (I do not know if this assumption is
true,
just riffing of the top of my head):

           FUTURERELEASE FOR;max-hold-for-value
           FUTURERELEASE UNTIL;max-hold-until-value

option 3:  assuming that there is no restriction on the number of
keywords
advertised by a single extension and there is no requirement that the
keyword(s) somehow reflect or align with the official name of the
extension
(again, I don't know if these assumptions are true...)

           HOLDFOR max-hold-for-value
           HOLDUNTIL max-hold-until-value

My preference is option 1, again because "my gut" tells me this is
cleaner,
and better fits the rules for SMTP extension frameworks, but again I
will
defer to the mail experts.

What say you?

Greg White

_______________________________________________
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: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 18 Oct 2005 07:43:24 -0500

If you wanted to offer non-redundant but sufficient info, you could declare the servers view of the current time and the max interval.  A client needing a future max time can compute it from the interval.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Eric Burger
Sent: Tuesday, October 18, 2005 4:06 AM
To: Greg White
Cc: [email-masked]
Subject: RE: [lemonade] Question 2: how to change the extension
framework

-----Original Message-----

Question 2:

What say you?

Greg White