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

From: "Greg White" <[email-masked]>
Date: Sun, 16 Oct 2005 22:42:41 -0500

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

---

From: Mark Crispin <[email-masked]>
Date: Sun, 16 Oct 2005 21:05:19 -0700 (PDT)

My feeling is that syntactic sugar is pretty much unimportant, as long as 
the functionality and the association of the syntax to the functionality 
is unambiguous.

-- 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: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Oct 2005 10:43:07 +0100

>but I will defer to the mail experts.
#2 seems better, because it is more clear on the fact that one can't 
specify both "holdfor" and "holduntil" values in the same MAIL FROM command.

>defer to the mail experts.
I don't think #2 is allowed. At least it might have peculiar effects on 
some mail clients.
#1 seems cleaner to me as well.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 18 Oct 2005 15:01:31 +0200

Alexey Melnikov writes:
> Greg White wrote:
>> 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.
>

mail from:<[email-masked]> hold=for;999 hold=until;...

The same issue seems to apply to RCPT TO...NOTIFY= in RFC 1891, and as 
far as I can remember, noone has raised that as a problem in the past 
ten years.

(I'm neutral on this. Some things are worth caring about, others not. I 
don't think it makes a problem wrt. syntax complexity either.)

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Oct 2005 14:06:19 +0100

> mail from:<[email-masked]> hold=for;999 hold=until;...

Not legal if you say that the "hold" parameter can appear only once.

> (I'm neutral on this. Some things are worth caring about, others not. 
> I don't think it makes a problem wrt. syntax complexity either.)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 18 Oct 2005 15:42:52 +0200

> Not legal if you say that the "hold" parameter can appear only once.

Indeed. So what? Equivalent text is possible for holdfor/holduntil.

The point is: RFC 1891 doesn't do it for NOTIFY AFAICT, and noone has 
raised an issue about that in the past decade, so the issue seems 
insignificantly small.

Arnt