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

[Matthew Wall <[e-mail]>]

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

<begin quote>


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

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