Re: use ldap as an adressbook in outlook listed all persons

[Terry Lambert <terry@whistle.com>]

Michael Helm wrote:
> 
> Terry Lambert writes:
> > The LDAP protocol is generally administratively prohibited
> > from returning all entries at once.  This has three intents:
> 1- spam prevention 2- overload 3- general case beyond #1, copyright
> 
> There are some situations where downloading the whole address
> book but having it managed by ldap are desirable.  For instance
> if you're a small or medium sized business, you have a lot of
> mobile employees, they need access to corporate phone books &c
> but it's become too much & too volatile to carry in their heads
> or in a book; they want it in their email client or pda &c &
> they want frequent updates.

You run into a distributed cache coherency problem when
you do this.

The most obvious way to deal with this is to run a replica
on the mobile client, and make that replica read-only (this
ignores the more complicated case of having both my personal
address book and my corporate one stored in the coporate
server, but we are talking about offline access, not client
independent access, so we can skip that for now).

Attempts to modify the cached copy will result in a referral.

The problems with doing this are that:

o	"LDAP" is not really very "L" because of the ASN.1
	stuff

o	There's no clean way to turn an offline referral
	into a quick "reject" using the current state of
	most networking software available for common
	desktop OSs

o	This doesn't deal with the issue where the mobile
	user is actually the company wide address book
	administrator (i.e. his "replica" is actually the
	autoritative source -- this is a special case of
	the replicated personal address book)

LDAP isn't very friendly to disconnected use, and LDAP
caching is not very safe, except in the case of a read-only
cache, and insensitivity of your application to potentially
large update latencies: a pretty specific application of
LDAP.


> The netscape DS & browser have an arrangement like that,
> it has some security (& some security lapses) for dealing
> with items 1 & 3.  The browser uses the replication
> capability of netscape DS to manage updates (which is mostly
> pure ldap, even tho replication per se is not standard ldap).

It really glosse over the cache coherency problems; the
user is forced into a particular data access and update
model, which might not really align very well with the
physics of the situation (i.e. laptop vs. desktop vs.
borrowed computer vs. kiosk with no user owned local
storage, etc.).

Think of the Microsoft Windows mobile user concept of
"briefcase synchronization", not of Palm-pilot style
pilot-to-host synchronization.

The more general protocol used for moving preference items
around is ACAP.  I'd even argue that the most desirable
feature of an address book or contact manager is the
automatic completion of partially type entries and/or
enumeration of all entries, with partially typed entries
causing selection of a scrolling window for alphabetic
"nearness" to the entry th user really wants.  PH goes
even further, adding soundex-style partial entry list
completion.


> Standardized ways of doing this would be a good thing.

Yes; though I'm not certain that this is really appropriate
as a use for an LDAP server, short of adding some more
extensions to make it even less "L" than it was.  In
particular, it would probably help partial entry completion
considerably for a single character 'x' to return only the
first entry for matching via 'xa*', 'xb*', ... 'xz*', and
there have been numerous calls for soundex-style matching,
as well as simple transaction support that could be used to
implement simple distributed coherency requirements.

Even so, you would have to index this search field, and
that would be (effectively) drawing a relation.

An extended LDAP could do the job, but a directory is more
like a registry than it is like a database.

I guess you could use the analogy that a directory is to a
database as operator assistance is to a phonebook.

Thoughts?

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.