RE: Named Referrals Questions.

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Well, what is missing from the LDAP perspective is that X.500 defined a
managed distributed object oriented information model for a directory
system and related to this object information model are protocols for
access, distribution and replication.

ie. X.500 and X.501 (the first parts) define the directory system and
its managed information model. Common Object Classes and Attributes for
this directory service are defined in X.520 and X.521.


For protocol access to this directory information, X.511 defined DAP,
X.518 defined DSP (chaining and distribution) and X.525 defined
replication (DISP).

If you read LDAP RFCs and ignore the noise re complexity, etc it is very
much based on DAP (X.511) and totally relies on the information model of
X.500 (and its management mechanism  eg subentries and op attrs, etc.)
ie one cannot just have an LDAP protocol without a basic X.500
information model and if one wants to evolve that to being a managed
object information model and deal with distribution and distributed
mutual authentication of users and access controls , it will naturally
get get very complex for those who consider DAP or LDAP  complex.


DAP or LDAP to a single server as a protocol is easy - just like a
telephone wire between a phone and a PABX. The next step is how big is
the telephone system and what service you want.


eg. For dealing with the reality of replicated ROOTs and how they get
engineered into product I can only suggest that all who have now reached
the end of the road with developing LDAP non distributed servers and
have to replicate everything to everywhere - revisit the root issues of
directories  (in X.500) and perhaps read a few of our white papers re
global backbones and multi master (opendirectory.com - white papers) and
our product specs to see how these root level distributed , fault
tolerant systems need to be engineered.

X.500 and X.511 is an abstract information model. Its implementation to
deal with root level issues, etc and redundancy at this level  is
product specific.

I hope this helps and regards alan


> -----Original Message-----
> From:	Christopher Lukas 
> Sent:	Thursday, July 29, 1999 11:44 PM
> To:	d.w.chadwick@iti.salford.ac.uk; ietf-ldapext@netscape.com
> Subject:	Re: Named Referrals Questions.
> 
> 
> David,
> 
> I think one reason we're having confusion here is that some people
> (you
> as well) are viewing LDAP from an X.500 perspective and others (me)
> are
> viewing it from an LDAP perspective. By that I mean that I have only
> briefly looked through the X.500 spec and was dismayed at the
> complexity
> so I have all of my directory knowledge from LDAP documents with a few
> references to the X.500 spec. 
> 
> That being said, I see in your online X.500 book (which is very nice)
> where you are getting these various names or types of entries. There
> seems to be a list of types for DSEs. This is new to me because they
> don't seem to be discussed in the LDAP protocol documents I have read.
> 
> However, I think I now understand what you mean by glue DSE, but am
> not
> clear on how these types of entries live in LDAP. I think we have
> created, in our slapd-based LDAP system, what essentially is a glue
> DSE.
> For various reasons, we actually have our entire DIT from the root
> down
> to the part that actually has data replicated across our distributed
> servers. Since we only have a 2-level tree, this amounts to having the
> root entry of our DIT replicated across all the servers, but I believe
> it may be a glue DSE in some sense. The reason it's there is so that a
> search starting at the root will work on any server without having to
> send a referral to a mythical central server that actually holds the
> root entry of the DIT. Because the servers are connected with what you
> call cross references, I believe, there is no need (or desire) to have
> a
> central server that actually has that entry.
> 
> But I still think we may be having problems that are coming from the
> X.500 <-> LDAP server/gateway interaction as opposed to the LDAP
> server/gateway <-> LDAP client. In your example below, since there
> don't
> seem to be "glue DSEs" defined in LDAP, I don't understand what you
> mean. 
> 
> Thanks.
> 
> - Chris
> 
> David Chadwick wrote:
> > 
> > >   If a client requests an operation for which the base or target
> object is
> > > not held by the server,
> > >
> > >   1. Remove the leftmost attribute/value pair from the DN.
> > >   2. If the remaining DN is empty - stop and proceed with superior
> > > reference from the root DSE.
> > >   3. If the remaining DN represents a locally held object that
> contains a
> > > ref attribute - stop and process referral.
> > >   4. If the remaining DN represents a locally held object that
> does not
> > > contain a ref attribute - stop and return "no such object" result.
> > 
> > Not quite correct I think. Try this insertion:
> > 
> > 4. If the remaining DN represents a glue DSE continue with step 1.
> > 
> > e.g. I request A,B,C,D and the server holds X,C,D as a cross
> > reference, C as a glue DSE and D as a glue or another cross
> > reference then I should be refered to either D or the superior
> > reference.
> > 
> > David
> 
> -- 
> ------------------------
> Christopher E. Lukas
> Internet Scout Project 
> http://scout.cs.wisc.edu