RE: Comments about draft-martin-managesieve-00.txt

[Edward Hibbert <[e-mail]>]

For the sorts of reasons you raise we are going to use our existing X.500
directory service, via LDAP.  To us (but I'm happy to accept not to
everyone), ACAP looks as though it's re-inventing another directory service
and access protocol, and we already have quite enough of those.  We have no
motivation to add ACAP support to our existing directory service.

Edward Hibbert.
DCL.

-----Original Message-----
From: Lawrence Greenfield [mailto:[e-mail]]
Sent: 15 February 2000 02:17
To: [e-mail]
Cc: Randall Gellens; Barry Leiba
Subject: Re: Comments about draft-martin-managesieve-00.txt


Ok, we're all interesting in getting ACAP servers out there.
I'd love to just use ACAP.  However, defining an "ACAP profile" to
handle Sieve scripts isn't as easy as it sounds.

For instance:
  I want to be able to share my Sieve script with my coworkers, but
  not my boss (I filter all of his mail).

For instance:
  Since we don't want the ACAP server and IMAP server necessarily
  sharing the same filesystem, 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.

Ok, great, now we need ACLs and contexts.  I'm sure I can justify just
about any other ACAP feature you want me to.

We (CMU) have a working ACAP server.  I'm willing to start putting
Sieve scripts on it next week.  I'd be extremely happy to say "we're
going to use ACAP" and see people implement ACAP servers to store
Sieve scripts.

I'm not sure this is going to encourage deployment of Sieve.

Or, rather: is anybody going to develop an ACAP server to deploy Sieve
in their products?

Larry

   Date: Mon, 14 Feb 2000 16:53:01 -0800
   From: Randall Gellens <[e-mail]>

   At 08:55 AM 2/8/00 -0500, Barry Leiba wrote:
   >I have to say that this whole thing seems a little excessive,
considering
   >the statement that this is an interim solution anyway:

   I agree.  I don't think it's a good idea to go the yet-another-protocol 
   route unless it moves us closer to where we want to be.

   My proposal all along has been to use ACAP or a subset.  We have
prototype 
   implementations of an ACAP profile for Sieve (along with a Sieve engine) 
   running on NT and Unix, and a prototype Windows GUI that manages scripts.

   By using an ACAP profile, both client and server support becomes pretty 
   easy, and the client can talk to a full ACAP server just as well as a
mini, 
   Sieve-only one.  So we get rapid deployment and move closer to a real 
   solution (full ACAP servers).