Philip Guenther wrote:
Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com> writes:
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:
...
Even with the examples, I still can't be sure what you mean by
"ignore".
Should the implementation "ignore the extension" by not supporting it,
returning error if it's used with 'require'? (This is what I originally
thought you meant and was the goal of my suggested rewording.)
Should it make its appearance in a 'require' a no-op, causing an error
later if any of the *flag actions or test are actually used?
Should it make the 'addflag' and 'removeflag' actions no-ops and the
'hasflag' test always return false?
Should it support the *flag actions and test completely and ignore only
the effect on the 'keep' and 'fileinto' actions?
I now _suspect_ the last is what you mean,
Yes.
in which case the extension
should perhaps be called the "atomset" extension, as all you're certain
of getting when you require it is the ability to manipulate sets of
atoms. (Okay, I'm being slightly facetious there, but only slightly.)
How about removing this sentence?
Section 5 already talks about ignoring flags that can't be stored, as
well as saying:
This document doesn't dictate how the Sieve interpreter will set
the [IMAP] flags. In particular, the Sieve interpreter may work as
an IMAP client, or may have direct access to the mailstore.