[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Named Referrals Questions.

Date sent: Thu, 29 Jul 1999 08:44:03 -0500
From: Christopher Lukas <lukas@cs.wisc.edu>
Organization: Internet Scout Project, University of Wisconsin-Madison
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.

Historically speaking LDAP was created by Tim Howes as a way of accessing X.500 directories and his first LDAP server was simply a protocol convertor between LDAP and DAP. Then when he ditched the Quipu (X.500) backend and built a DB into his stand alone LDAP server, the first real LDAP server (SLAPD) was born. But the models and ideas of the LDAP server and service have always been X.500 compatible, which is why LDAP is used to access pure X.500 and proprietary X.500-like servers (an eg of the latter is Novels NDS).

So I think it is perfectly legitimate to view LDAP from an X.500 perspective, since this is where its root lie (and where most of the rules that it lives by are defined - still by reference to the X.500 standard I might add). THe problem comes when people dont know much about X.500 and hence dont know too much about the underlying and supporting models from which LDAP was created. My book on the net might help alleviate this, as you have found.

Of course, LDAP now has a life of its own (the son is greater than the father) and divergence may occur between the two sets of standards. But I think that would be a shame and a general dis- service to users, so if there is no sensible reason for doing so (and I dont call religious arguments a sensible reason) then we should endeavor to ensure that the LDAP and X.500 knowledge models are the same. They already share the same distribution model based on naming contexts, so the same knowledge model (albeit with different attribute syntaxes) seems sensible to me - at least in the first instance until we find it is deficient in some way.

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

Not quite correct. The root DSE is specified in the LDAPv3 documents

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

A glue DSE is a simple concept, it is simply the name of node in the DIT, and the server that holds the glue DSE only knows the name of the node and nothing else about it (i.e. it does not hold any of the attributes associated with that entry)

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

Then you have EXACTLY the same model as X.500. Each X.500 server holds all the DSEs from the root downwards to the start of the naming context(s) that it holds. SOme of these will be glue DSEs, some not e.g. an immediate superior reference DSE, or an administrative point DSE (the latter is not yet really recognised by LDAP 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.

No, the root DSE is not a glue because it holds some attributes such as myaccesspoint (or my knowledge ref), a superior reference, types of LDAP controls supported etc etc. A glue DSE holds nothing (except perhaps a type bit to say it is a glue).

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

This will not happen with pure X.500 servers, since they all recognise that the root entry is not a proper entry and is not searchable like other entries.

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

The root entry does not exist in the X.500 world, but every DSA does have a root DSE.

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

I hope I have explained them now, and you can see the purpose of them. Try reading the example I gave below again, only substitute for glue DSE "the entry holds no attributes at all". You will see that your algorithm fails in this event (of course you have to have an LDAP server that is subordinate to several other LDAP servers for the failure to occur)

David

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


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************