Ken Murchison wrote:
0.2. Open issues
1. Do we want to use special actions that work with global state or use
optional tagged arguments?
Allow both? Currently the draft allows both models.
As stated earlier (in response to Tim's post) I'm in favor of both.
Me too.
Any other voices?
2. If we decide to keep both, what "keep"/"fileinto" without tagged
arguments means: don't set any flags
or use global flags? I would rather ignore flags completely to keep
current "keep"/"fileinto" behavior.
This breaks backward compatibility with the previous draft and if
this is a big concern it can be addressed
in the next revision of the draft.
I think that keep/fileinto without any tagged arguments SHOULD use the
global flags. If someone wants to keep/fileinto a message without the
global flags (if any), we could allow one of the following syntaxes:
keep :flags ""; OR
keep :flags NIL; OR
keep :noflags;
I would like to hear Tim's opinion on this.
IMHO, the first works fine for me.
5. ":globalflags_plus" and ":globalflags_minus" names are ugly.
Suggestions are welcome.
I think we can get rid of ALL of the :globalflags* options for two
reasons:
1. They make the syntax more crufty (and they ARE ugly as you state :^)
2. The same results can be obtained using existing mechanisms.
Examples:
keep :globalflags; = keep; (see point 2. above)
keep :globalflags_plus "foo"; = addflag "foo"; keep; removeflag "foo";
keep :globalflags_minus "foo"; = removeflag "foo"; keep; addflag "foo";
Although it is mathematically equivalent, it is not very convenient :-).
Besides, as a current user (and implementer) of imapflags, I really
haven't come across the need to tweak the global flags on a per
keep/fileinto basis. If I did find a need for this, I wouldn't have any
problem either overiding the globals completely by using :flags or
bracketing the keep/fileinto with addflag/removeflag as I've shown
above.
5. Interaction with Other Sieve Actions
Sieve actions sometimes prohibit each other in order to make
filtering scripts less likely to cause serious problems.
The SIEVE interpreter MUST ignore any [FM]
actions when they are used with reject. The SIEVE interpreter MUST
ignore these
commands when no keep (implicit or explicit) or fileinto actions will be
taken.
If the script uses any of [FM] actions
together with reject a SIEVE verifier SHOULD warn the user using
available means that
the script contains actions that has no effect when used with reject.
Is it really necessary to make a special case for reject? What's the
point of provding a warning? The [FM] actions are ONLY useful for
actions that actually deliver messages (keep, fileinto), and all other
actions (redirect, reject, discard, vacation, etc) should just ignore
them as stated above.
Ok, you convinced me :-). I'll remove all restrictions on reject/discard.
One other comment...
I think this has been mentioned before, but none of the [FM] actions
described in the draft seem very IMAP specific. Why couldn't these
mechanisms be used for setting any mailstore specific flags? Granted,
no other use comes to mind right now, but shouldn't we error on the side
of flexibility? Just a thought... feel free to flame :^)
Do you have anything particular in mind? (Using IMAP Annotations is worth
separate draft.)
Do you have any proposals how to change the draft?
Alexey