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

Lawrence Greenfield <leg+@andrew.cmu.edu> Tue, 15 February 2000 02:14 UTC

Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28702 for ietf-mta-filters-bks; Mon, 14 Feb 2000 18:14:07 -0800 (PST)
Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28698 for <ietf-mta-filters@imc.org>; Mon, 14 Feb 2000 18:14:05 -0800 (PST)
Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id VAA19091; Mon, 14 Feb 2000 21:17:18 -0500 (EST)
Date: Mon, 14 Feb 2000 21:17:18 -0500
Message-Id: <200002150217.VAA19091@smtp3.andrew.cmu.edu>
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ietf-mta-filters@imc.org
Cc: Randall Gellens <randy@Qualcomm.Com>, Barry Leiba <leiba@watson.ibm.com>
In-reply-to: <4.3.0.20000214164856.00beec30@randy-nt4.qualcomm.com>
Subject: Re: Comments about draft-martin-managesieve-00.txt
References: <389BD7B1.58CC11F7@messagingdirect.com> <4.3.0.20000214164856.00beec30@randy-nt4.qualcomm.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ietf-mta-filters@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

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 <randy@Qualcomm.Com>

   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).