Re: Architecure Draft [Dont Use Copy]

["Ed Reed" <ED#032#REED@xxxxxxxxxx>]

The question you raise, Alan, drives directly to the question of what must be done to LDAP to be able to use it as a distributed directory service.

Not much discussion, here or elsewhere, has been given to how the community of LDAP servers on the Internet provide for a global namespace, connected conviently via DNS, for clients to peruse.

It's that last bit - that clients peruse - that is the kicker.

Novell chose, in our directory, to chain exactly one operation at the DSA for clients - the Resolve Name operation.  The fuction is easily reproduceable in an LDAP extended operation, and that's probably where it belongs.

While clients MAY do their own name resolution processing, all our application-oriented clients "let the server do the walking", returning a referral to one or more servers which match the criteria set out by the client as necessary - must we talk to the "primary" replica?  Is an updateable replica required, or will an read-only do?  Does the client require a certain version of the DSA software to be supported because of some special features it wants to support?  And, of course, what's the DN of the entry the object wants to access, or the base name of the search it wants to perform?

Obviously, figuring that all out taking into account sparse and fractional replicas will be interesting, but we're really only talking about how a client gets directed to the server that holds the information that will best suit the client's needs.  Servers, who already have open, authenticated connections among themselves for replication purposes, and who already have ready, local, access to all the replication agreement information about the name contexts they hold, about the name contexts which are subordinate to the name contexts they hold, and about the name contexts superior to the root-most name contexts they hold...well, the servers have much of the information needed to compute a quick referral to the client, and so we let them.  In fact, the Resolve Name operation even returns a handle to the object named in its request, so if the client is going to read or modify the entry, no further searches need to be performed.  Similarly, if the entry is missing, or not available due to access control policy, an error is returned so the client won't waste any more of its time.

But - the specification of that operation, or of the logic needed to perform the work (essentially documented in X.518, section 18.6, pretty literally - a flow chart in Figure 8/X.518 called "Find Naming Context" of the original 1988 spec, in fact) is outside of the replication specification, and so we leave it, for now, to the reader, and to the author who would like to flesh out the details.

Ed

-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320