Subject: draft-melnikov-sieve-imapflags-03

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Sep 2000 17:12:24 -0700

>    All actions described in this specification (setflag, addflag, removeflag,
>    mark, unmark) operate on an internal variable that contains the set of 
> [IMAP] flags
>    associated with the message being delivered. When the interpreter 
> starts executing
>    a script this variable contains an empty set. The 'addflag' action 
> adds flags
>    to the existing set. The 'removeflag' action removes flags from the 
> existing set.
>    The 'setflag' action replaces the existing set of flags with a new set.
>    Whenever the interpreter encounters a 'fileinto' or 'keep' action it files
>    the message with the current set of flags.

I'm not comfortable with the specification of an internal variable.

I'd prefer that the draft stick to the semantics of the operations.  As I 
see it, the actions added by this extension modify IMAP flags on the 
message being processed.  If the message is eventually kept or filed, the 
flags go with it.  If the message is deleted, the flags are meaningless.

'setflags' undoes any previous flag actions and causes the specified flags 
to be set.

'addflag' sets the specified flags.

'removeflag' cancels the specified flags from being set.

Also, I think the descriptions of 'mark' and 'unmark' are unclear.  They 
should specify exactly what is to happen, and not have so many MAY do this 
or that statements.

I like the idea of setting flags independently of 'fileinto' or 
'keep'.  I'd really much rather not have 'fileinto'/'keep' be a way of 
setting flags.

I think the wording on 'reject' is too strong.  What's wrong with making it 
a no-op to set flags on a message which is then rejected or discarded?  A 
script editor can always warn "this has no effect" to the user, but that's 
its business.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Sep 2000 17:34:34 -0700

I think the draft should say why it is needed, that is, why not just use

     if address :contains :localpart ["to", "cc", "bcc"] "+foo"

Also, should the draft deal with the fact that not all systems use "+" as 
the character which introduces subaddresses?

---

From: Ken Murchison <[email-masked]>
Date: Tue, 12 Sep 2000 15:43:34 -0400

>      if address :contains :localpart ["to", "cc", "bcc"] "+foo"

The problem is that this will match both 'user+foo' and 'user+foobar'
which we may not want.

The :user and :detail options provide the same functionality as the
:localpart and :domain options -- they all allow for exact matches on
the various pieces of the address.

Without having variables, the :detail option doesn't have much, if any
use IMHO.  But the :user option is valuable when people use detailed
'from' addresses.  For example, if I want to do something with all
messages from you, I'd use:

if allof (address :user "from" "randy", address :domain "qualcomm.com")

This will catch mail from you whether you use "randy", "randy+sieve",
"randy+imap", etc.  This being said, the best way to do this (and any
other complex address match) is via the regex extension, eg:

if address :regex "from" "randy(\\+.*)?@qualcomm.com"

> the character which introduces subaddresses?

Yes, it should probably mention this fact.

The only reason that I wrote (and implemented) this extension was that
is was suggested in [SIEVE] that such a thing might be desirable.  I use
:user in my own scripts, but with the regex extension, I can get by
without ANY of the address part options (even though they are cheaper
CPU-wise).

Due to the apparent lack of interest on the list, I was planning on just
letting the draft expire.  If there happens to be an unexpected
groundswell of support, then I'll go ahead and tweak the draft.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Randall Gellens <[email-masked]>
Date: Tue, 12 Sep 2000 14:55:27 -0700

I think it's useful.  You also bring up a good point, which is that 
if a Sieve implementation supports userdetail, the ":user" portion 
of an address does *not* include the detail.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 12 Sep 2000 21:34:32 -0400

> of an address does *not* include the detail.

So, you think that I should continue work on the draft?

Are you suggesting that the capability should be userdetail instead of
subaddress?  I really don't like subaddress and have been searching for
something better.

Do you have any problems with :user and :detail as the optional
arguments?  Suggestions for something better?

Any suggested text for discussing different user/detail separators?

Thanks,
Ken

---

From: Randall Gellens <[email-masked]>
Date: Tue, 12 Sep 2000 19:06:44 -0700

>  So, you think that I should continue work on the draft?

I think so.  Anyone else?

>  subaddress?  I really don't like subaddress and have been searching for

Doesn't much matter to me.  I think "userdetail" may be more 
familiar to those who know what the feature is.

>  arguments?  Suggestions for something better?

Works for me.

>  Any suggested text for discussing different user/detail separators?

I'd probably have a new section between current 2 and 3, called 
"Definitions" or some such, and say something like:

--------

A system supports user-detail addressing (also sometimes called 
"subaddressing") if there is a character which can be appended to 
the local part of an email address such that it and all following 
characters of the local part are ignored for purposes of 
determining the addressed user.  This character is called the 
"detail separator" and is often a plus sign ("+").  Generally, 
email systems which support user-detail addressing attempt to 
deliver a message into the user's mailbox whose name matches the 
detail.  If such a mailbox doesn't exist, or if the delivery is 
into a single-mailbox location (such as POP), the detail is ignored.

For example, a message addressed to "[email-masked]" might be 
delivered into a mailbox called "q" belonging to the user "susie". 
If Susie does not have a mailbox "q", the message is delivered into 
the default location.

-------

Later on, I'd say that if a Sieve implementation supports the 
"userdetail" capability, the ":user" portion of an address does not 
include the detail separator or the detail.  For example, the 
address "[email-masked]" has a ":user" portion of "susie", a 
":detail" portion of "q", a ":localpart" of "susie+q", and a 
":domain" of "example.org".

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Sep 2000 22:02:07 -0600

Randall Gellens wrote:

> >    associated with the message being delivered. When the interpreter starts
> executing
> >    a script this variable contains an empty set. The 'addflag' action adds
> flags
> >    to the existing set. The 'removeflag' action removes flags from the existing
> set.

So you like the idea, but you don't like the wording (more precisely the
explanation).

> should specify exactly what is to happen, and not have so many MAY do this

Barry originally said that draft is too tied to IMAP. mark/unmark allows to specify
importance of the message without enforcing the way how it is implemented.

> 'keep'.  I'd really much rather not have 'fileinto'/'keep' be a way of

As I've heard voices from both sides (from people who want to use separate commands
or to use tagged arguments) I can't make judgment which way is preferred.
I will have both in next draft and hopefully I will hear more comments.

> script editor can always warn "this has no effect" to the user, but that's

Sure. I can relax wording.

Alexey

---

From: Randall Gellens <[email-masked]>
Date: Sat, 16 Sep 2000 22:11:34 -0700

>  So you like the idea, but you don't like the wording (more precisely the

Yes, I like very much being able to set IMAP flags with Sieve.

I just think the draft should specify what happens when the new 
commands are used, and leave the underlying implementation alone.  I 
realize you were introducing the global variable concept to help make 
your point, but I personally think it's better so simply say that 
this command adds a flag, this command takes away an added flag, etc. 
If the message is kept, the flags (if any) are also kept.  If the 
message is discarded, the flags have no effect.

>  importance of the message without enforcing the way how it is implemented.

I think it makes it harder to interoperate, especially since this 
affects the email client.  Perhaps what we need instead is to give up 
using IMAP flags for this, and use Annotations instead.  Sounds like 
the message/priority is needed here.

>  I will have both in next draft and hopefully I will hear more comments.

I think the draft should make it clear that this is an open issue: to 
have separate commands, bundle with keep/fileinto, or both.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Sep 2000 23:22:47 -0600

Randall Gellens wrote:

> your point,

In fact I was trying to explain the concept in mathematical terms (set
operations), but it might be to academic for the purpose.
Sorry, my brains just work this way :-).

> but I personally think it's better so simply say that

Add/take away flags to/from what?
If you don't say "internal variable" you will use "message", thus you assume there
is some internal "storage" for the current list of flags, i.e. "variable".

> >  Barry originally said that draft is too tied to IMAP. mark/unmark
> > allows to specify importance of the message without enforcing the way how it
> is implemented.
>

Are you proposing to bound mark/unmark to IMAP Annotation or drop it?

> have separate commands, bundle with keep/fileinto, or both.

Ok

Alexey

---

From: Randall Gellens <[email-masked]>
Date: Sat, 16 Sep 2000 23:15:51 -0700

>  is some internal "storage" for the current list of flags, i.e. "variable".

Add/take away flags to/from the message.  Conceptually, the message 
has flags.  Certainly in an IMAP-accessed message store it has flags.

I'm really only saying that the language should stick to the 
semantic/logical/conceptual level, and not get into global variables.

>  Are you proposing to bound mark/unmark to IMAP Annotation or drop it?

There was talk of a Sieve extension for IMAP annotations.  It could 
be added to yours on flags, but because of timing it probably is more 
desirable to do it separately (so yours doesn't have to wait on 
annotations).

---

From: [email-masked]
Date: Sun, 17 Sep 2000 14:33:07 -0700 (PDT)

> Ken Murchison wrote:

> It definetely make sense and simplifies SIEVE scripts.
> So I say "go ahead".

Agreed.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Sep 2000 15:25:28 -0600

Alexey.