Subject: I-D ACTION:draft-ietf-sieve-imapflags-00.txt

From: [email-masked]
Date: Tue, 08 Feb 2005 15:40:25 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-00.txt
	Pages		: 0
	Date		: 2005-2-8
	
Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 09 Feb 2005 00:29:33 +0100

a few comments:

the default comparator is always "i;ascii-casemap", so it can be omitted
from the examples.

the actions and tests allows a list of flags to be specified as a space
delimited string.  I assume this is intended to allow variable
references.  e.g.:

  set "s" "\\Answered Closed";
  setflag "f" ["${s}", "\\Deleted"];
  if hasflag "${f}" "${s}" ...

do we really need "setflag"?  it is equivalent with "set", except it
allows some syntax checking of the arguments, but as you can see above,
it can't really do much of it statically anyhow.  I think most users
will use "addflag" almost exclusively.

-- 
Kjetil T.

---

From: [email-masked]
Date: Tue, 08 Feb 2005 16:28:06 -0800 (PST)

> allows some syntax checking of the arguments,

And possibily duplicate elimination and reordering.

> but as you can see above,
> it can't really do much of it statically anyhow.

Yes, but runtime checking is possible.

> I think most users

Without setflag I would expect to see stuff of the form

    set "foo" "";
    addflag "foo" "bar";

Whether or not this savings warrants an entire action is a judgement call.
Having implemented it I can say that for me at least supporting setflag only
amounted to about 15 additional lines of code and one additional table entry.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2005 11:35:43 +0000

>the default comparator is always "i;ascii-casemap", so it can be omitted
"i;ascii-casemap" is not used in examples, it is used in the Implementation Notes section, where it is required.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 09 Feb 2005 14:50:00 +0100

On Wed, 2005-02-09 at 11:35 +0000, Alexey Melnikov wrote:
> "i;ascii-casemap" is not used in examples, it is used in the
> Implementation Notes section, where it is required.

I don't think so.

RFC 3028, 2.7.3.   Comparators
   [...]
   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase characters in the ASCII subset of UTF-8 as
   the same).  If left unspecified, the default is "i;ascii-casemap".

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2005 14:03:23 +0000

>   the same).  If left unspecified, the default is "i;ascii-casemap".
Fine :-). I certainly didn't remember this, so I don't think it hurts to 
be explicit.

Alexey

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 12:00:56 -0500

> Without setflag I would expect to see stuff of the form

Is the first line strictly necessary?  i.e. can you manipulate variables
via addflag et al if those variables haven't been instantiated?
I would think that you could.

> amounted to about 15 additional lines of code and one additional table entry.

I think having extra stuff in the language is more the point than how
hard it is to add that extra stuff.  I would also prefer not to have
verbs that aren't really needed.

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 12:07:21 -0500

Some more random comments.

1. Introduction

   > This extension depends on the presence of "variables" extension
   > [Variables].

Should you mention that this isn't an automatic dependency?  i.e.
that the script writer still has to require variables?

> <<Extension name has been changed as revision 03 of this document is widely
> deployed in CMU Cyrus server>>

Isn't this problematic in terms of the relationship between drafts
and implementations?

2.1. General requirements for flag handling

   >  A string
   > containing a space separated list of flags ...

nit:  "space-separated"
(repeat for other occurances in the document)

   > If a flag validity check fails the flag should be silently
   > dropped, but a warning message should be logged by the Sieve interpreter.

nit one:  I would say "ignored" since "dropped" could be read as
"removed from the message" rather than "not paid attention to in the
Sieve statement."  (Even though the flag wouldn't be associated with the
message if it's invalid: but I'm talking English grammar here, not
logic.)

nit two:  I would use a word other than "logged" -- warnings may
be issued in other ways than logging.

nit three: should "should" be "SHOULD" ?

nit four: if the error should be reported, in what way is it silently
ignored?

3. Actions

   > The "set" action
   > defined in [Variables] can be used to replaces an existing set of flags
   > with a new set as well.

nit: "replace" (instead of "replaces")

3.1. Setflag Action

        > if header :contains "from" "[email-masked]" {

Prohibition on using real domain names in documents?  (i.e.,
"example.edu")  Repeat for other occurances in the document.

4.  Test hasflag

I'm having a hard time understanding what this test does in other than
simple cases.  

   > The "hasflag" test evaluates to true if any of the variables matches any
   > flag name.

Does this mean "contains any of the flags listed in list-of-flags" ?
or "contains all of the flags listed in list-of-flags"?
or "matches (according to match-type) the concatenation of flags
contained in all of the list-of-flags strings, subject to canonical
re-ordering"?

Does each string in "list-of-flags" contain exactly one flag, or can
each string be a list of flags as in other usage?

Perhaps more examples would help.

6. Implementation Notes

   > "addflag <variable> <flag>" can be implemented as:
   > 
   >  if not string :matches :comparator "i;ascii-casemap"
   >     " ${<variable>} " "* <flag> *" {
   >      set <variable> "${<variable>} <flag>"
   >  }

Note that you'll get a superfluous leading space if <variable> starts
out empty.  Probably doesn't need saying, though, except that the
following "removeflag" example goes to great pains to remove leading
and trailing spaces.

   > "removeflag <variable> <flag>" can be implemented as:
   > 
   >  if string :matches :comparator "i;ascii-casemap" " ${<variable>} "
   >     "* <flag> *" {
   >      set <variable> "${1}${2}";
   >  }

Should be "${1} ${2}", no?

10. Extended example

   > elsif anyof (not address :all :contains
   >                ["To", "Cc"] "[email-masked]",
   >              header :matches "subject"
   >                ["*make*money*fast*", "*university*dipl*mas*"])
   >         {
   >         remove "MyFlags" "\\Flagged";
   >         # If message header does not contain my address,
   >         # it's from a list.
   >         fileinto :flags "${MyFlags}" "spam";   # move to "spam" folder
   >         }
   > else
   >         {
   >         # Move all other (non-company) mail to "personal"
   >         # folder.

My eyes may be glazing over, but have we really established
"non-company" mail at this point?  One of the ways we get here
is if "to" or "cc" contain "[email-masked]"

mm

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2005 17:51:25 +0000

>I would think that you could.
I guess you are right (assuming the script writer is not reusing the 
variable "foo"), but I am not sure I approve this as a good script 
writing technique.

>verbs that aren't really needed.
I prefer to have "setflag" for consistency.

---

From: [email-masked]
Date: Wed, 09 Feb 2005 10:39:32 -0800 (PST)

> via addflag et al if those variables haven't been instantiated?

You can but it is beside the point. The issue is that the variable may
have been previously initialized to have some other value.

> I would think that you could.

You can, but again, that's beside the point.

> verbs that aren't really needed.

Implementation difficulty is definitely a factor to consider IMO, as is whether
or not the verb will actually be used. Stuff that's hard to implement increases
the liklihood of bugs, as does having stuff that's rarely used (rarely used
code is often a place where bugs lurk).

This, BTW, is why I'm basically opposed to the proposals to add associative
arrays to the language. Implementation of such facilities is going to be
complex and since it will have to be a separate extension the odds of it
being widely used are low. This is a recipe for bugs, and when you consider
that there are other ways to do all of this...

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2005 18:55:14 +0000

>that the script writer still has to require variables?
I've added:
   This means that a script using this extension MUST list both 
"variables" and "imap4flags" in a require statement.

in order to clarify.

>Isn't this problematic in terms of the relationship between drafts
It is surely is, but I don't know a generic solution for the problem.

>(repeat for other occurances in the document)
fixed.

>message if it's invalid: but I'm talking English grammar here, not
Ok.

>nit three: should "should" be "SHOULD" ?
Yes.

>nit four: if the error should be reported, in what way is it silently
Maybe the better way of conveying my idea is to say that a failure to 
set a certain flag doesn't stop other flags from being set and doesn't 
cause a runtime error.

>nit: "replace" (instead of "replaces")
Thanks.

>"example.edu")  Repeat for other occurances in the document.
Fixed.

>contained in all of the list-of-flags strings, subject to canonical
"any flag name" means the first choice.

>each string be a list of flags as in other usage?
The intention was to have the former. I will try to clarify.

>Perhaps more examples would help.
Yes.

>following "removeflag" example goes to great pains to remove leading
Ok.

>Should be "${1} ${2}", no?
Good catch, thanks.

>is if "to" or "cc" contain "[email-masked]"
Everything which is not from the known mailing lists, non-company 
related (not sent/addressed by/to people from the company) and addressed 
to me goes to "personal".

Thank you for the comments!
Alexey

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 14:16:01 -0500

> have been previously initialized to have some other value.

Yeah, I would say that it would be poor practice to reference an
uninitialized variable.  The question about being able to reference an
unitialized variable was a tangential wondering.

As to whether you would always see those pairs of statements together:
probably not, at least for me.  In practice I would probably initialize
the variable in some preamble and then adjust it as necessary.
Certainly another "set" to "" could be used if needed.

> code is often a place where bugs lurk).

OK, but "let's avoid it because it's hard to implement" is quite different
from "let's add it in because it's easy to implement."  My point is
let's consider whether we need it or not, and not just add it because
it's easy.  Syntax clutter is still clutter even if it's easy.

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 9 Feb 2005 14:28:12 -0500

> to me goes to "personal".

The point is that I don't think that's true where that comment says
it is.  When you get to that point, you can have the "To" or "Cc"
field containing "[email-masked]" which seems to indicate a
company-related message.

Is my mental interpreter failing?

mm

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 09 Feb 2005 22:09:36 +0100

> "any flag name" means the first choice.

yes, this is in line with the behaviour of other tests, e.g.

  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]

> The intention was to have the former. I will try to clarify.

if so, '[ "A B" ]' must be handled differently from '"A B"', which seems
to be in conflict with RFC 3028.  see section 2.4.2.1:

   Conversely, in any case where a list of strings is appropriate, a
   single string is allowed without being a member of a list: it is
   equivalent to a list with a single member.  This means that the test
   `exists "To"' is equivalent to the test `exists ["To"]'.

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Feb 2005 00:03:37 +0000

>  address :localpart ["To", "Cc"] ["kjetilho", "alexey"]
Exactly.

>to be in conflict with RFC 3028.  see section 2.4.2.1:
You assume that a list-of-flags = ["A", "B"] is the same as ["A B"]. I 
originally didn't make such assumption, but I might be convinced that 
this is the right thing to do.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Feb 2005 22:57:49 +0000

>field containing "[email-masked]" which seems to indicate a
Right, we are actually talking about the same thing :-).
When we get to this branch, it means that a message was sent by somebody 
outside of the company.
I called this "personal" mail.

So yes, the comment should be updated.

>Is my mental interpreter failing?
No, I needed to reboot mine :-).

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Feb 2005 13:56:14 +0000

Kjetil Torgrim Homme wrote:

>On Fri, 2005-02-11 at 00:03 +0000, Alexey Melnikov wrote:
>  
>
>I'm not sure I do.  what is clear:  the argument is a list of strings.
>according to 3028, a list containing only one string may omit the
>brackets.  in other words,
>["A B"] MUST be the same as "A B".
>
I've just realized that we are talking about different things. The 
original question was whether "A B" is interpreted as ["A", "B"]. And as 
you pointed out below, the answer I gave to Mark recent was wrong.

And yes, ["A B"] is the same as "A B", even for the hasflag test.

>  whether this is the same as ["A",
>"B"] is a matter open for debate, but your draft currently say that they
>are:
>
>   hasflag :is "MyFlags" "b A"
>   [...] can be also written as
>   hasflag "MyFlags" ["b","A"]
>  
>

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 11 Feb 2005 14:44:46 +0100

["A B"] MUST be the same as "A B".  whether this is the same as ["A",