[Top] [All Lists]

Re: Action Interaction

2004-11-05 12:21:53

On Fri, Nov 05, 2004 at 11:30:26AM +0000, Alexey Melnikov wrote:
Tim Showalter wrote:
In general, I agree, and I will try to incorporate these changes into 
the next draft.

Alexey Melnikov wrote:

3). Need to state that "reject" and "discard" are incompatible.

They aren't clearly incompatible.  If keep+discard aren't 
incompatible, why would reject+discard be incompatible?

Section 2.10.4 says:
  Implementations SHOULD prohibit reject when used with other actions.

Right, so it depends on whether implementations implement
this SHOULD.  (With ours, it's configurable.)
I'm not sure why something other than the quoted statement is needed.

But I don't follow this logic:

I frankly don't care either way, but this must clearly be stated. Either
a). when both discard and reject are requested, reject is executed

Apart from the SHOULD in 2.10.4 (and the application-level
considerations behind it), I don't see what the technical
problem with executing discard and reject is.  Discard cancels
the implicit keep.  Reject sends a nastygram and cancels the implicit
keep.  So, discard + reject do the same as reject alone, just
like discard + fileinto do the same as fileinto alone.

Not because someone explicitly said so; the math just works
out that way.

b). the last one of discard/reject is executed (i.e. discard also 
cancels a previous reject)

No!  Please, no time travel.

c). discard and reject are incompatible (as discard is a silent reject 
and one can't reject silently and not silently at the same time).

That would be the right thing to do for implementations that
implement the SHOULD in 2.10.4.  (Not because "discard is a
silent reject"; it isn't, although that may be the way some
people chose to think about it.)

The normal *user* idea of "discard;" is usually better
expressed by "discard; stop;" -- don't file it, and don't
do anything else with it, either, because after something
is discarded (in the English sense of the term), it is gone.
But that's not how the sieve discard action is defined--it
just cancels the implicit keep.


<Prev in Thread] Current Thread [Next in Thread>