Jutta Degener wrote:
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.)
Why? Why not have two separate actions instead?
I'm not sure why something other than the quoted statement is needed.
But I don't follow this logic:
As you noted below I am trying to redefine what "discard" means based on
the English meaning of the word. The mailing list archive confirms that
many people got confused by the definition of "discard", so maybe we
should adjust its definition.
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.
I never said there is a technical problem. I am just trying to use the
usual meaning of the words.
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.
or
b). the last one of discard/reject is executed (i.e. discard also
cancels a previous reject)
No! Please, no time travel.
There is no time travel for implementation that execute all actions
after the script interpretation, as opposed to executing an action at
the time of interpretation.
But I am Ok with not requiring this.
or
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.
I don't really like that there is a choice between a) and c). Can we
just pick one? There is already too much optional stuff in Sieve.
Alexey