Philip Guenther wrote:
In section 1, I suggest changing
Sieve interpreters that don't support integration with IMAP SHOULD
ignore this extension.
to
This extension is only appropriate for sieve interpreters that
support integration with IMAP.
(What does it mean for an interpreter to 'ignore' an extension?)
I still the original sentence is better. Below are some examples that explain
the motivation for this sentence:
1). Somebody writes a generic Sieve implementation that uses callbacks for
specific functions like get a header field or set a flag. For example Cyrus
Sieve implementation.
The generic implementation can recognize presence of imap4flags, but might be
unable to set an IMAP flag, because the application hasn't provided a callback
for setting flags.
(Arguably one can treat this as a bug, so maybe the following example is more
interesting.)
2). A particular installation might not be able to set IMAP flags, because it
uses a proprietary API for message delivery and the configured mailstore
backend doesn't support IMAP flags.
3). Even if integration with an IMAP mailstore is supported, this doesn't
guaranty that a particular mailstore backend would support setting IMAP flags.