Subject: [lemonade] final future release question (I think)

From: "Greg White" <[email-masked]>
Date: Tue, 28 Feb 2006 19:47:51 -0600

Hi folks,

I am finishing up what I believe to be the last version of the Future
Release draft, and I need to take a vote:

Regarding the syntax of parameters on the MAIL command:

The draft currently specifies the following:

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

Back in 11/05, Randy Gellens and Mark Crispin expressed a preference for the
following:

         future-release-interval = future-release-integer

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

         hold-for-param = "HOLDFOR=" future-release-interval

         hold-until-param = "HOLDFOR=" future-release-date-time

The reason I chose the first method was:
   1)  This forces the client to choose only one method of future release,
and the server only has to look for one HOLD parameter on the MAIL command.
   2)  OK, so the server still has to parse the two subvalues in the HOLD
value to figure out what to do, but we already know how to do that (e.g. the
ORCPT parameter of the DSN extension).
   3)  In my mind, having two HOLD parameters makes it easier for the client
to screw up;  i.e. putting both parms on the MAIL command, which certainly
the server should reject.  But now the server has to make that check.

Randy and Mark, could you state again (I apologize) why you like the two
parm version better?

Finally, if anyone has strong preferences one way or another, let me know,
and highest score wins.  I'll get it in and we can LC this thing.

Thanks,
Greg

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 28 Feb 2006 18:01:14 -0800 (Pacific Standard Time)

I have two objections to your proposal.

First, I see nothing in RFC 2822 that prevents a client from specifying 
multiple parameters with the same name.  Consequently, I think that your 
concern against HOLDFOR= and HOLDUNTIL= is misplaced; a client can just as 
easily have HOLD=for; and HOLD=until; in the same command.

Second, I think that your proposed HOLD=for;20 syntax is bizarre (not to 
mention ugly).  Is there any precedent for such use of semicolon in SMTP? 
I'm not aware of any (I admit that I haven't been keeping careful track). 
Where I have seen semi-colon used with parameters, it has been as a 
delimiter between parameters as in MIME.

Consequently, my vote is against your proposal, and for HOLDFOR= and 
HOLDUNTIL= as previously discussed.

-- Mark --

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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 01 Mar 2006 02:25:48 +0000

On Wed Mar  1 02:01:14 2006, Mark Crispin wrote:
> First, I see nothing in RFC 2822 that prevents a client from 
> specifying multiple parameters with the same name.  Consequently, I 
> think that your concern against HOLDFOR= and HOLDUNTIL= is 
> misplaced; a client can just as easily have HOLD=for; and 
> HOLD=until; in the same command.
> 
> 
Agreed.

> Second, I think that your proposed HOLD=for;20 syntax is bizarre 
> (not to mention ugly).  Is there any precedent for such use of 
> semicolon in SMTP? I'm not aware of any (I admit that I haven't 
> been keeping careful track). Where I have seen semi-colon used with 
> parameters, it has been as a delimiter between parameters as in 
> MIME.
> 
> 
IIRC, DSN uses them for ORCPT, as Greg said, stuff like 
ORCPT=dns;[email-masked] - but this is purely based on my 
highly fallible memory. The argument as presented is firstly a 
mitigation, and secondly only has effect where DSN is already 
supported.

> Consequently, my vote is against your proposal, and for HOLDFOR= 
> and HOLDUNTIL= as previously discussed.
> 
> 
Your original argument being that hold-for would not gain any new 
values that ought to make it through last call, essentially.

I agree (with this argument of Mark's, and thus I'm for 
HOLDFOR/HOLDUNTIL) on the basis that I cannot conceive of any, and 
none have been presented.

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