Re: REPOST: LDAP and ACAP, from an IMAP point of view

Gordon Irlam (
Thu, 20 Feb 1997 18:51:01 -0800 (PST)

LDAP is the user directory service Microsoft and Netscape are both
commited to using. Netscape already sells an LDAP server. It is
probably the most important new protocol since HTTP.

ACAP is a service designed to store user preferences.

Here are some good bits on both.


>>From Thu Feb 20 18:53:56 1997
>Sender: (Tim Howes)
>Date: Thu, 20 Feb 1997 14:19:50 -0800
>From: Tim Howes <>
>Organization: Netscape Communications Corp.
>To: Jack De Winter <>
>Subject: Re: REPOST: LDAP and ACAP, from an IMAP point of view
>References: <>
>Jack De Winter wrote:
>> okay, I am on the IMAP list, as well as the ACAP list,
>> and I am trying to figure out the entire ACAP versus
>> LDAP thing.
>> Would someone be able to help me out by clearly stating
>> what the design goal of LDAP is, and how extending LDAP
>> to cover what ACAP is covering is a good idea? I know that
>> this may be a volatile subject, but I simply want to know
>> where LDAP is right not, and how LDAP could be made better
>> or worse by going into ACAP territory (so to speak).
>> >From my limited reading and exposure on the subject, I thought
>> that LDAP was supposed to be used for the broadcasting of
>> read-only directory information, and limited changes to some
>> of that information. For example, an addressbook or a company-
>> wide lookup database (I want to send mail or phone Phil Smith,
>> please give me the pertinant information, thanks).
>Sorry for not responding sooner. Here are some thoughts
>on ACAP and LDAP.
>When I look at ACAP and LDAP, I see like 90% overlap.
>They both provide an an attribute/value-based storage
>mechanism. They both allow you to search the information
>they store. They both allow you to update the information.
>Etc. Doing this basic stuff is where the majority of work
>in providing any service like this lies.
>Where do they differ? It's helpful to understand where
>they come from first. ACAP comes to its current general
>state from a more specific one, aimed at providing these
>services in support of IMAP. LDAP comes to its current
>state from one where it was tied to X.500. Both ACAP and
>LDAP suffer from the perception of their roots.
>One claim you'll hear is that ACAP is targeted at less
>structured information, less central administration, more
>autonomous control by applications and users, and that
>LDAP is not. This is not really true, and this is where
>LDAP suffers from the perception that it's restricted
>to front-ending X.500, and X.500 suffers from the perception
>that the model it defines is only good for the globally
>managed white-pages-style directories you're used to seeing.
>There are three issues at the heart of this:
>1) Schema. Perception: LDAP schema must be centrally
>managed and controlled and adding additional elements,
>say for your application, requires contacting some central
>administration. Fact: Schema in LDAP is in the hands
>of each server. If a server wants to allow clients to
>store anything they want, without applying any schema
>rules, it's free to do so. Yes, there are common sets
>of schema elements defined for white pages and other
>applications that can benefit from such things. No,
>your application doesn't have to use it if it's not
>2) Namespace. Perception: LDAP names are all hierarchical
>and step one to bringing up an LDAP directory is figuring
>out what your "root" is and registering yourself with some
>central naming authority - kind of a pain if all you want
>to do is store your preferences. Fact: LDAP has no such
>restriction. If you want to configure your LDAP server to
>hold entries directly under the root, you can easily
>construct a flat namespace, or a hierarchical one of your
>own that starts from the root. The protocol makes no
>requirement about this. The namespace you've see in the
>LDAP/X.500 white pages world is not one you need to tap
>into to provide a preference store.
>3) Data distribution. Perception: To use LDAP as a preference
>store means extending people's existing white pages entries
>with attributes to store preferences. Since these two types
>of data seem to have different requirements, read/write
>ratios, replication requirements, etc., this appears bad.
>Fact: There's no need to have one gigantic uber-entry for
>each person in the directory, certainly not as far as LDAP
>is concerned. A better strategy that I'd advocate is using
>LDAP much the same way that ACAP has been proposed: have
>a separate server co-located (or not) with your mail server
>or other related things. Yes, I'd want a pointer in my
>LDAP entry in the corporate directory to my LDAP entry in
>the LDAP "preference server", but no, there's no requirement
>for them to be the same.
>These problems of perception can be dealt with easily by
>a little education on both sides. More fundamental questions
>are raised by considering the real areas in which the
>two protocols differ, and there are some.
>ACAP provides built-in support for quotas. LDAP does not.
>What would LDAP need to handle this? I'm thinking just an
>operational attribute that expresses how much over/under
>quota a user is, but maybe I don't fully understand the
>ACAP provides primitives for off-line operation, and
>syncing up once you reconnect to the network. LDAP does
>not. How hard would this be to do in LDAP? I don't fully
>understand how what ACAP has solves this differently
>than an LDAP client caching data and defering update
>operations until it connects back up, which can be
>done today. I may need some education, though.
>There are probably a few other things, as well.
>The danger in using LDAP instead of ACAP is made in
>the "LDAP is my hammer and every problem is starting
>to look like a nail to me" argument. In other words,
>the problems the two protocols address are different
>and deserve different protocols as solutions, rather
>than one uber-protocol to solve everything. It's a
>compelling argument, but only if you buy into the
>premise and into some of the misconceptions about LDAP
>that I mentioned above.
>The other side of the coin is that if you believe,
>as I do, that there is tremendous overlap in the two
>protocols, there is obviously a real cost to developing
>and deploying an entirely new protocol and infrastructure
>to support it. If you can leverage existing LDAP code
>and installed base, things get a lot easier, from
>development, to deployment, administration, etc. Do
>we want to end up with a different directory protocol
>for every kind of application? White pages, yellow
>pages, configuration storage, preference storage,
>document meta-information, etc. etc. Obviously not.
>So where does this leave us? Well, Chris Newman and
>I have had it on our plates for a while now to sit
>down and write up some kind of document that describes
>where we think the two protocols are going, how they
>differ, might coexist, etc. Neither one of us has
>had time to push this effort, unfortunately.
>But having learned more about ACAP over the past
>few weeks, and having thought about things a little
>I guess I've come to the following conclusion. There
>are two things I could see happening that I'd be
>willing to support.
>1) Use LDAP to solve this problem. If we need to add
>a couple of extensions to do it, that still seems
>easier to me than developing a whole new protocol
>from scratch. Seems like we should at least try, given
>the cost of the other path. If we go this route, and
>it works, there's no need for ACAP.
>2) Radically simplify ACAP so it really provides a
>simple store/get service for configuration information.
>Much of the complexity it has is in trying to do
>sophisticated search and update, access control, etc.
>None of this stuff is needed if it's really meant to
>just solve the configuration access problem. LDAP can
>do this too, of course, but I can certainly see some
>benefit in defining a new very simple (authenticate,
>store, retrieve) protocol for this purpose - no sense
>making people implement LDAP if this is all they want.
>So, that's a brain dump from me on the subject. I don't
>want to touch off a storm of controversy, but I do
>think it's time we started thinking about these issues.
>Sorry for being so long-winded, but I hope this helps
>clear up some of your confusion. I'd be very interested
>to hear what other people think about this too.
> -- Tim
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873

Author of SLMail for 95 & NT (