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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 03 Oct 2005 13:18:51 +0100

Philip Guenther wrote:

>The two sample implementations of "addflag" should be next to each
>other.
>
>
>The sample "removeflag" implementation in section 6 is incorrect, as it
>will only remove a single occurence of the given flag.  (Even if
>"addflag" performs duplicate elimination, "removeflag" must still handle
>multiple occurences as the user may have altered the variable directly
>with "set".)
>  
>
After talking to Philip I would like to suggest to remove this section. 
Would anybody be upset with this?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Oct 2005 00:06:47 +0100

Philip Guenther wrote:

>I think the third sentence of section 3.2 should be flipped around, if
>just to avoid "MAY NOT" (while "MAY" is an RFC 2119 keyword, "MAY NOT"
>isn't!).  Indeed, I would give the implementation even more leeways,
>ala:
>   The addflag action MAY alter the flag list in any way that leaves the
>   its semantics as a set of case-insensitive words unaltered.  For
>   example, it may reorder the flags, alter the case of the letters in
>   them, or add or remove duplicates or extraneous spaces.  Scripts
>   SHOULD NOT make assumptions about the ordering of flags in lists or
>   the preservation of their case.

Ok.

>Hmm, written like that, that chunk probably belongs in section 3 and not
>3.2, especially when generallized to cover "setflag" and "removeflag" as
>well.

Done.

>The above also obsoletes the second paragraph of section 6 ("A script
>interpreter..."), which seemed oddly placed to me anyway.

As previously suggested - I've removed the section 6.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Oct 2005 13:42:00 +0100

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.

---

From: Philip Guenther <[email-masked]>
Date: Sun, 16 Oct 2005 19:54:24 -0700

Alexey Melnikov <[email-masked]> writes:
>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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Oct 2005 10:35:07 +0100

Philip Guenther wrote:

>I now _suspect_ the last is what you mean,
>
Yes.

> in which case the extension
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.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 18 Oct 2005 13:31:28 -0700

>>>>  Sieve interpreters that don't support integration with IMAP SHOULD
...<discussion elided>...
>How about removing this sentence?

That works for me.

BTW, I suggest dropping "referenced by a variable" from the description
of :flags in section 3, as the flag list used with :flags doesn't
require variables.  Indeed,
	keep :flags "";
is useful as a way to ignore the internal flag list variable.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Oct 2005 12:35:26 +0100

>>How about removing this sentence?
Done in my copy.

>is useful as a way to ignore the internal flag list variable.
I agree.