Support for Internet Message Access Protocol (IMAP) Events in Sieve
RFC 6785
Yes
No Objection
Recuse
Note: This ballot was opened for revision 06 and is now closed.
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document. Please
consider the following Comments.
---
Section 2.1
Only one "imapsieve" capability string, specifying one sieveurl-
server, can be present.
Are you sure? Or do you mean "More than one "imapsieve" capability
string MUST NOT be present"? And then a description of how to process
the error case.
---
Section 2.2.4 (see also 3.8)
In a server that advertises "imapsieve", messages whose flags are
changed in any way (except as explained in the next sentence) MUST
trigger the execution of a Sieve script, subject to the settings
defined through Metadata. The exception is that in order to avoid
script loops, flag changes that are made as a result of a script that
was itself invoked because of flag changes SHOULD NOT result in
another script invocation. In any case, implementations MUST take
steps to avoid such loops.
Yes, the script recursion or loop is to be avoided.
But isn't what you have here too strict?
Might you not have a script that reacts to a flag (X) that is set by a
command. That script sets another flag (Y). Then you want a script that
reacts to flag (Y) being set.
I think you probably only need that a script MUST NOT be invoked more
than once in the sequence of events following a "top-level" event
(presumably a command or "cause" in the language of 4.3).
Noting that 2.3.1 has:
Only one Sieve script may currently be defined per mailbox,
I wonder whether this debate is moot.
---
Section 2.3.1
Support for IMAP events in Sieve requires support for IMAP Metadata
[RFC5464] as well, since the latter is used to associate scripts with
IMAP mailboxes.
Want to play with that so it is in 2119 language?
---
Section 3.3
If a keep action is NOT also in effect, the original message is then
marked with the \Deleted flag (and a flag-change Sieve script is NOT
invoked).
I don't think the emphasis of uppercase "NOT" is needed.
We find similar text in 3.4 and 3.5.
---
Section 3.3 (this paragraph is having a bad day)
The implementation MAY then expunge the original message
(WITHOUT expunging other messages in the mailbox), or it MAY choose
to have expunges batched, or done by a user.
I find this ambiguous. I cannot tell whether one of the three actions
MUST be selected, or whether each action is OPTIONAL (and mutually
exclusive).
We find similar text in 3.4 and 3.5.
---
3.11
Future extensions that are specifically designed to respond to
delivery of a new email message will likewise not be applicable to
this extension.
This is fine, but I wonder whether you want to move this text to a new
subsection "3.12 Future Seive Actions".
In that section, I think you also want to require that new
specifications of Seive actions must specifiy their interaction with
the function defined in this document.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
As noted in the Gen-ART Review by Roni Even on 22-Aug-2012, at the end of sections 3.7 and 3.8 "acton" should be "action"
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss, No Objection, Discuss) No Objection
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection
(Barry Leiba; former steering group member) Recuse