Subject: [lemonade] imap-sieve: shold EXPUNGE be an imap-sieve event?

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Jul 2007 17:56:59 -0400

Taking the in-person discussion to the mailing list:
Alexey would like "EXPUNGE" to be an imap-sieve event.

The options are three:

1. Leave things as they are: "EXPUNGE" is NOT an imap-sieve event.

2. Add "EXPUNGE" as a new imap-sieve event, which would invoke the script BEFORE 
the message is removed from the mailbox.  This would allow all actions that are 
allowed by the other events, including KEEP (cancel the expunge) and DISCARD 
(continue with the expunge).  This is a little inconsistent with other events, in 
which the script is invoked AFTER the event has happened.

3. Add "EXPUNGE" as a new imap-sieve event, which would invoke the script AFTER 
the message is removed from the mailbox.  This is consistent with other events, 
in that it invokes the script after the event has happened.  It separates into 
two subcases:

3a. Allow the possibility that the server will no longer have the message 
available.  Early implementations of IMAP4rev1, before Mark declared them 
"broken", would delete messages as soon as they were expunged, even if not all 
clients had been informed of the expunge yet.  Such implementations might have to 
use this option.  On the other hand, such implementations would have to limit the 
valid actions to ones that can be performed on a message that's gone -- which I 
think limits us to NOTIFY.  (For what it's worth, I think this is a non-starter, 
but I wanted to include it for completeness.)

3b. Require the server to keep the message around for script processing.  This 
would allow all the actions, including KEEP (put the message back... but note 
that it would now be a NEW MESSAGE, and other clients will have been notified of 
the expunge and then of the storing of a new message in the mailbox).

In either case 2 or case 3b, we would have to sort out details of the 
interactions among actions.  For instance, it probably doesn't make sense to have 
an "implicit KEEP" here -- we probably have an "implicit DISCARD" instead.  If 
the action we take is to change flags on the message, does that "cancel the 
implicit DISCARD", and turn it into a KEEP?  Or what?

So... what do people think we should do here?  We talked about allowing two weeks 
for comments, before making a decision here.  Vote early and often (this said 
from Chicago, you see).

Barry

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 01:42:24 +0300

Hi All,
Alexey explained that His NOTIFY implementaiton includes some hooks and He realized that it would be a good idea adding a hook for EXPUNGE as well (please correct if I misunderstood something).
Before making a choice I would like to ask Alexey whether there is a real-world scenario for this (and it is not going to be added "just for the fun of it").
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Barry Leiba [mailto:[email-masked]] 
>Sent: 25 July, 2007 00:57
>To: [email-masked]
>Subject: [lemonade] imap-sieve: shold EXPUNGE be an imap-sieve event?
>
>2. Add "EXPUNGE" as a new imap-sieve event, which would invoke 
>the script BEFORE the message is removed from the mailbox.  
>This would allow all actions that are allowed by the other 
>events, including KEEP (cancel the expunge) and DISCARD 
>(continue with the expunge).  This is a little inconsistent 
>with other events, in which the script is invoked AFTER the 
>event has happened.
>
>3. Add "EXPUNGE" as a new imap-sieve event, which would invoke 
>the script AFTER the message is removed from the mailbox.  
>This is consistent with other events, in that it invokes the 
>script after the event has happened.  It separates into two subcases:
>
>3a. Allow the possibility that the server will no longer have 
>the message available.  Early implementations of IMAP4rev1, 
>before Mark declared them "broken", would delete messages as 
>soon as they were expunged, even if not all clients had been 
>informed of the expunge yet.  Such implementations might have 
>to use this option.  On the other hand, such implementations 
>would have to limit the valid actions to ones that can be 
>performed on a message that's gone -- which I think limits us 
>to NOTIFY.  (For what it's worth, I think this is a 
>non-starter, but I wanted to include it for completeness.)
>
>3b. Require the server to keep the message around for script 
>processing.  This would allow all the actions, including KEEP 
>(put the message back... but note that it would now be a NEW 
>MESSAGE, and other clients will have been notified of the 
>expunge and then of the storing of a new message in the mailbox).
>
>
>In either case 2 or case 3b, we would have to sort out details 
>of the interactions among actions.  For instance, it probably 
>doesn't make sense to have an "implicit KEEP" here -- we 
>probably have an "implicit DISCARD" instead.  If the action we 
>take is to change flags on the message, does that "cancel the 
>So... what do people think we should do here?  We talked about 
>allowing two weeks for comments, before making a decision 
>here.  Vote early and often (this said from Chicago, you see).
>
>Barry
>
>
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 24 Jul 2007 16:45:04 -0700

It seems that adding EXPUNGE as an event that triggers the Sieve 
script adds a lot of complexity and turns the usual meaning of the 
Sieve world on its head (the implicit keep becomes and implicit 
discard or else a script that takes no action blocks action).

I suggest we leave it out, at least for now (it can always be added 
as an extension).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Give thought to your reputation.  Consider changing name and moving
to a new town.