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

From: Edward Hibbert <[email-masked]>
Date: Tue, 15 Feb 2000 09:37:06 -0000

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:[email-masked]]
Sent: 15 February 2000 02:17
To: [email-masked]
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 <[email-masked]>

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Feb 2000 09:36:45 -0800

At 9:37 AM +0000 2/15/00, Edward Hibbert wrote:

>ACAP looks as though it's re-inventing another directory service
>and access protocol

This perception is not uncommon, but the intent of ACAP is not to be 
a directory access protocol at all, but rather a very easy way for 
clients to access data on a central server that is normally kept on 
the local hard drive.  Client configuration and preference data, for 
the most part.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
How does a project get to be a year behind schedule?
One day at a time.   --Fred Brooks in _The Mythical Man Month_

---

From: Matthew Wall <[email-masked]>
Date: Thu, 17 Feb 2000 23:08:19 -0500

-- On Tuesday, February 15, 2000 9:36 AM -0800 the entity known as Randall 
Gellens <[email-masked]> wrote:

<begin quote>

> This perception is not uncommon, but the intent of ACAP is not to be a
> directory access protocol at all, but rather a very easy way for clients
> to access data on a central server that is normally kept on the local
> hard drive.  Client configuration and preference data, for the most part.

<end quote>

To which Matthew Wall offers this response on Thu, 17 Feb 2000 23:02:07 
-0500:

I would add somewhat parenthetically is that some kinds of data -- things 
like user email addresses, for example -- tends to be identical but be 
treated in different ways depending on the context of management and user 
access. Directory data, for instance, is a bit different from the way you 
want your personal addressbooks to be handled: the example I usually give 
is you probably want your Aunt Millie's address in your personal 
addressbook and maybe shareable with your wife, but not in the corporate 
directory.

Sieve filter strings I expect will have similar provenance -- on the one 
hand, there will be times when they may best be stored as part of a 
directory, others where they're appropriate to client preference data.

Speaking from the client side of things, from a client that may wish to use 
sieve strings in a disconnected mode (e.g. with no LDAP server available), 
but where some communication with a remote server is nice for resynching 
from time to time, the ACAP model works a lot better. The email client 
program treats a user-based and defined filter as yet another preference, 
in effect. LDAP can be miserable if you try to overload it with too much of 
this stuff.

I do agree that ACAP would be the best management route in the best of all 
possible worlds, but don't really see a problem using LDAP or whatever 
works in a given environment if the deployment warrants it...we've even 
experimented with IMSP 8-).

- mw

PS Larry's comments are well-taken, however, about implementation humps.