Subject: Progressing draft-melnikov-sieve-imapflags-04

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Fri, 14 Mar 2003 13:36:19 -0800

Five suggestions to the draft.  

Way back On Tue, 2002-07-16, Tim Showalter wrote:

>Cyrus Daboo wrote:
>> 
>> | Tim thought that in order to do this right, we need to introduce
>> | variables in Sieve.
>> | So I am waiting for either:
>> | 1). draft that adds Sieve variables
>> | 2). a desire to standardize draft-melnikov-sieve-imapflags-04.txt as is
>> | (with an implicit variable).
>> 
>> One option might be to get rid of the ':globalflags...' tagged arguments 
>> and all the actions and instead only rely on the ':flags' tagged argument 
>> for fileinto and keep. I believe that gets rid of the need to have any 
>> variables during the lifetime of the script, and provides a basic 
>> implementation that can be built on later if variables are introduced.
>
>I agree with this.  :globalflags mostly bothered me with respect to
>variables.
>

Suggestion 1:

I suggest :globalflags not be removed at least unless a draft and 
implementation adding Sieve variables is well underway.
-As Ken has said, being able to set a flag once is useful, 
 and with variables, something like 

   keep [VariableName, "\\Answered", "$MDNSent"]; 

would work.  

This example makes a complexity of variables evident though - could VariableName be a string-list?  
Adding variables isn't trivial.

Suggestion 2, regarding 3.4, quoted below (Of course, if all implicit 
variables are to done away with, 3.4 mark and unmark would need to go 
too, so these changes are moot.):

3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked as urgent. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well. Thus the mark  action is
   semantically equivalent to 'addflag "\\Flagged"'.

   The unmark action allows the flag previously  set  by  the Mark action to be unset.
   Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark.
   Unmark MUST NOT unset any other flags. This means that the following script does nothing:

      mark;
      unmark;

   The unmark action is semantically equivalent to 'removeflag "\\Flagged"'.

Several little problems: if mark sets more than one flag, 
then the last sentence is false.  If the message is already marked, then 
mark; unmark; does SOMETHING.  It Removes the flag(s) the first mark set.  
Does the \Flagged flag necessarily imply the message is "urgent", 
as the first sentence claims? 
Also, why would mark want to set other flags?
Lastly, unmark cannot unset flags other than \Flagged set by other 
implementations, because it cannot know what they are.

Suggested replacement text:

3.4. Mark and Unmark Actions

   Syntax:   mark

   Syntax:   unmark

   The mark action allows a message to be marked. Conformant implementation MUST
   set \Flagged [IMAP] flag, but MAY also set other [IMAP] flags as well.  

   The unmark action allows the flag previously set by the Mark action to be unset.
   Unmark MUST unset the [IMAP] \Flagged flag and all other flags that could be added with mark by the implementation.
   Unmark MUST NOT unset any other flags. 

Suggestion 3:
IMHO, the RFC would be useful if the following was added:

I would follow the sentence in 5. "The SIEVE interpreter MUST ignore these
   commands when no keep (implicit or explicit) or fileinto actions will be taken."
with "Thus, for example, scripts should set flags before fileinto, not after!"

Why: it's non-obvious to sieve script writers, who get caught by this 'gotcha'.

#A counterexample:
#The following doesn't make sense: the Seen flag isn't set in any message store, 
#because it isn't followed by a keep or fileinto which would cause it to do so.
#If you want the copy in test1 to be marked as seen, reverse the order of the fileinto 
#and addflag commands.  Perhaps an implementation SHOULD flag this as an error.  
#But perhaps not; I think an implementation couldn't catch all such errors, 
#except at runtime, so trying to catch some isn't very helpful. 
if header "subject" :contains "test1"
{
   fileinto "test1 folder";
   addflag "\\Seen";
   stop;
}

Suggestion 4:

There's a typo : "If non of the 4" should read "If none of the 4"

Suggestion 5:

address :all :contains
                  ["To", "Cc", "Bcc"] "[email-masked] <mailto:[email-masked]>",

is nonsensical; it should be changed to 

address :all :contains
                  ["To", "Cc"] "[email-masked] <mailto:[email-masked]>",

because there is no Bcc header in received email.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 23 Mar 2003 17:27:04 -0700

> Five suggestions to the draft.

[Sorry, I had problems with my laptop this week].

> mark; unmark; does SOMETHING.  It Removes the flag(s) the first mark set.

Yes, unmark shouldn't remove any flags not settable by mark.

> Does the \Flagged flag necessarily imply the message is "urgent",

I believe the consensus of IMAP community is that this is the case.

>    Unmark MUST NOT unset any other flags.

Ok, I agree with all your comments regarding mark/unmark. However, as mentioned earlier these two commands will be dropped
from the document.

> if header "subject" :contains "test1"

Ok, I've updated my copy. But once again, as the decision was to use variables, this will be dropped in the future
(however I keep a copy of all changes if somebody comes up with a counter argument

> There's a typo : "If non of the 4" should read "If none of the 4"

Fixed.

> because there is no Bcc header in received email.

Changed.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________