ietf-mta-filters
[Top] [All Lists]

Re: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt

2005-10-16 20:26:40

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, 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.)


Philip Guenther