RE: A philosophical question about large directory structures

+ 
+ disjunct namespaces are subspaces of a larger namespace, and thus no 
+ problem, namespacewise. It might be a problem discovery-wise.
+ the naming problem is with overlapping namespaces, or namespaces not 
+ guaranteed to be non-overlapping.

Hmm, if you impose a name space or several disjunct ones, then an entry for Harald Alvestrand could only found by me using that name space if I have access to a directory server that somehow (direct or indirect) knows about a directory server that holds this entry. So the server holding Harald's entry has to be registered (whatever that means) at some other server in the DIT. Due to the fact that you use imposed name spaces this registration may be extremely distributed (I register my server at the barber shop at the corner, who is registered at a residential directory server and so on to the top). This is the Paradise model, though you might be able to use a different registration procedure.

Referrals are URL's and therefore always unique. So if you register at an referral server no name spaces are imposed. Now what is the difference between registering according to the imposed name spaces and registering to an ldap referral server? It is still a matter of registering (again, without having a clear idea about what registering should be). The difference would be that the distribution according to a DIT is no longer possible. And probably one would need many more (i.e. more elaborated) ldap referrals without imposed name spaces than with them. I don't think that is a big deal. Many other possibilities are still open.

The focus IMHO should be on the registration (or discovery) of servers and heir content. Not on the name spaces.

+ >The real problem is standardizing object classes and attributes so that 
+ >people can actually read information from each other's directories.
+ 
+ interesting - this came up > 1 time now....

I noticed a rather extensive discussion on the ldap-ext list regarding the top objectclass ;-)

Peter Jurg
M&I/STELVIO