Support for Internet Message Access Protocol (IMAP) Events in Sieve
RFC 6785

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.

  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"