Re: Storing filters in LDAP

I think we'll see UIs that expose a subset of Sieve functionality to 
users, very much like today's mail client filter UIs.  The UI itself 
will generate and interpret Sieve syntax (and will probably punt on 
interpreting complex Sieve scripts and present an edit box).
How the UI accesses the Sieve script is n interesting question.  My 
Email Accounts draft (draft-ietf-acap-email-02.txt) suggests using an 
ACAP dataset for email account information.
We have prototype code that includes an NT GUI for Sieve creation and 
editing, a mini-ACAP server for accessing the Sieve script, and a 
Sieve execution engine.  The actual Sieve script is stored in a file, 
but this is invisible except to the mini-ACAP server and the Sieve 
execution engine.
I can also see people implementing various other access methods 
including email and HTTP.
I think ACAP is attractive because it allows the client to get 
extension information and syntax errors and the syntax is very easy 
on both the client and the server, and there is no need for a full 
ACAP server -- the mini-server (just for Sieve) works well.