Subject: RE: [lemonade] draft-ietf-lemonade-imap-sieve-00

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 19 Dec 2005 08:50:11 -0600

I don't understand the big picture here.

In earlier discussions, we determined there were four cases where filtering occures:
	AF: Administrative filtering upstream of user processing
	DF: Traditional deposit time filtering
	NF: Filtering of notification events (maybe including notification actions resulting from deposit events?)
	VF: View filters of messages in a mailbox.

This draft appears to me to address DF filters where "deposit" comes from the IMAP client.  Is that a correct reading?  My alternate guess is that this specifies a means of performing a view filter by automatically (re)foldering messages into an alternate mailbox, in which case you want to capture all trigger events to apply the view filter to.

Can you map this document to the above filtering model or suggest changes to the model?

This draft also does not discuss the management of the scripts.  Are you assuming MANAGE SIEVE?  I would prefer to see a fuller script management interface included in IMAP that subsumes basic management capabilities of the SIEVEFILTER command.  

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Barry Leiba
Sent: Monday, December 19, 2005 12:14 AM
To: [email-masked]
Subject: [lemonade] draft-ietf-lemonade-imap-sieve-00

I have just sent the attached draft to be published as an I-D.  It's a
first pass at describing an extension to IMAP and Sieve that could be
used to drive server-to-client notifications with a Sieve script.

Please review and comment here, and especially note the "open issues"
section.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Stephane H. Maes" <[email-masked]>
Date: Mon, 19 Dec 2005 14:59:56 +0000 GMT

I am working on the mapping and examples. Give me a few days to see if it works. I will try to allign with this new draft and extend to NF.

I think this is how we agreed to proceed in Vancouver

Stephane
_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle
Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!) or [email-masked] (MSN Messenger)

-----Original Message-----
From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 19 Dec 2005 08:50:11 
To:Barry Leiba <[email-masked]>, [email-masked]
Subject: RE: [lemonade] draft-ietf-lemonade-imap-sieve-00

Greg V.

-----Original Message-----

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Dec 2005 22:09:48 -0500

Greg says...
> This draft appears to me to address DF filters where "deposit" comes
> from the IMAP client.

Stéphane says...
> I am working on the mapping and examples. Give me a few days to see
> if it works. I will try to allign with this new draft and extend to
> NF.

Stéphane has basically answered Greg's question, that it falls into
NF.  But it could also fall into DF, as Greg suggests.  I don't see,
right now, where lemonade would need DF filtering at the IMAP
APPEND/COPY level, but this will enable that if it be needed.

Background: This actually came up on Paris, not Vancouver, only I
didn't get the time to write the draft by Vancouver time.  In Paris,
Stéphane was talking about s-to-c notifications, and I suggested that
Sieve be used, since it's got a notification framework in the works.
Stéphane agreed that it might be usable if we extended things so that
Sieve scripts were called at times other than mail delivery, and I
volunteered to write a draft to get us going on it.

> This draft also does not discuss the management of the scripts.  Are
> you assuming MANAGE SIEVE?  I would prefer to see a fuller script
> management interface included in IMAP that subsumes basic management
> capabilities of the SIEVEFILTER command.  

Right, it doesn't.  It puts in a placeholder for some of it, with the
SIEVEFILTER maybe-command, but I'm not, in general, happy with how
Sieve scripts can (more properly, can't) be managed.  The managesieve
protocol is too limited.  It assumes that there's one active Sieve
script per user, and that there either is or isn't an active script.
That's fine when Sieve scripts are only called for mail delivery, but
not if we start calling scripts at other times: Now we find we need to
consider different scripts for different causes, and perhaps (for
efficiency or management purposes) specify which mailboxes trigger the
script(s) and which don't.  Maybe there are other issues too.

I'm not sure we'll get consensus on an extensive script-management
interface in IMAP -- it's quite an overload for IMAP.  That's why I
left the "SIEVEFILTER" command unspecified, and just there as something
to open discussion on the issue.  Managesieve can certainly be
extended, and perhaps this draft should add another section, replacing
the SIEVEFILTER stuff, that extends managesieve to handle causes and
multiple active scripts, at least.

Do others have comments there?

Barry

---

From: Rob Siemborski <[email-masked]>
Date: Tue, 20 Dec 2005 19:17:06 -0800

On 12/19/05, Vaudreuil, Greg M (Greg) <[email-masked]> wrote:

> This draft also does not discuss the management of the scripts.  Are you assuming
> MANAGE SIEVE?  I would prefer to see a fuller script management interface included in
> IMAP that subsumes basic management capabilities of the SIEVEFILTER command.

Could we please strive to not throw everything *and* the entire
kitchen sink into IMAP?  MANAGESIEVE may not be perfect, but it can be
improved without integrating into the IMAP protocol stream.

In any case, SIEVEFILTER seems ripe to be an annotation instead of a
command (though then we can have the discussion about ACAP-in-IMAP
instead :).

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

---

From: Ken Murchison <[email-masked]>
Date: Wed, 21 Dec 2005 21:16:15 -0500

> improved without integrating into the IMAP protocol stream.

Agreed.

> command

Yes.  We use a /vendor/cmu/cyrus-imapd/sieve mailbox annotation for 
running a sieve script on a shared mailbox (bboards in CMU-speak).

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Ken Murchison <[email-masked]>
Date: Wed, 21 Dec 2005 21:21:45 -0500

> Do others have comments there?

I think we need to either extend MANAGESIEVE or use mailbox annotations 
(Cyrus currently does the latter for running a script when a message is 
delivered to a shared mailbox)

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Dec 2005 13:32:41 +0300

>> Do others have comments there?
Disclaimer: I haven't made my mind yet on whether running Sieve scripts 
on IMAP events is a proper thing.

> I think we need to either extend MANAGESIEVE or use mailbox 
> annotations (Cyrus currently does the latter for running a script when 
> a message is delivered to a shared mailbox)

Both seems like reasonable approaches. However I have slight bias 
towards extending ManageSieve to allow for multiple Sieve triggers, as 
this seems to provides better abstraction layer. Mailstores that 
implement generic mailbox annotations can still use mailbox annotations 
to store Sieve scripts.