At 09:17 PM 2/14/00 -0500, Lawrence Greenfield wrote:
However, defining an "ACAP profile" to
handle Sieve scripts isn't as easy as it sounds.
There are always going to be features that are desired in any Sieve access
protocol. The goal behind using a Sieve profile is to make it as easy as
possible to deploy a protocol that meets the absolute minimum, and is
upwardly extensible (by going to full ACAP).
I want my IMAP server to be able to
open contexts on my ACAP server that stores the scripts. This way I
don't have to do an ACAP search for every message delivery but I
won't use out-of-date Sieve scripts.
You could also have an active client that opens contexts on the full ACAP
server in which the Sieve scripts are stored, and when any of them change,
pushes the change to the Sieve server. But that's not my point. My point
is that people are going to want a lot in a Sieve access protocol, and
developers want something that is very easy to implement and deploy. I
think a minimal ACAP subset meets the second goal, and provides a way to
reach the first goal.