[aklug] Re: FNL Classes

On Wed, 5 Dec 2007, Lee wrote:

> Most excellent. This is exactly the sort of 'detail' that is missing in most
> discussions, but once overtly stated helps a whole bunch of other stuff fall into place.
>
> This is the exactly the kind of thing I need to hear, anyway. These are just a few of
> the many questions (sanitized, of course) that I have asked myself just with openldap
> over the years. "what's an o? what's an ou? what exactly is a dc? ok, they are
> technically interchangeable, I get it. So why do you need three (or more)? what's a
> dn? when do you use a dn vs a dc vs a ??. OK, most everything is technically
> interchangeable, so where do I find the conventions that are typically used.". Plus
> many many more.

You're asking some very loaded questions. First off, bare in mind that LDAP
was designed to implement X.500-compliant directory services. The reality
is that the directory has no real common root, but starts out with two
branches that have weak linkage between them. You have the Organizational
model (implemented with o=) and the Domain model (implemented with dc=).
The Organizational model is shallower, but much richer in the kind of
information stored in it, while the domain model can be much deeper, but
stricter in the associated data. Depending on what you need a directory for
one might be more applicable than the other. For ISP & e-mail related
purposes, the domain model typically makes more sense.

The resource for describing this is probably going to be the RFCs, in which
case you'd probably want to start with rfc1279:
ftp://ftp.rfc-editor.org/in-notes/rfc1279.txt .

The dn comes from the realization that LDAP is essentially an object
database. Getting your head around ODBMS is difficult for most of us,
especially those of us grounded in RDBMS. The dn is basically the only true
globally unique index by which you can retrieve an object. Since virtually
identical objects can exist within different scopes (think in terms of
different branches) their scope becomes a crucial differentiator between the
objects. Let's go to the overused analogy of a telephone directory. If
you want to talk to John Smith, you'd better know which office, street, or
something, in order to get the right one, right?

There are practical computing efficiences as well, which save the trouble of
maintaining and distributing a universal index. "Distributing" is a key
word here, as well, since a primary design goal is to allow delegation of
branches or subtrees to other directory servers. The dn allows you to make
your way to the authoritative server for that object. LDAP can easily be a
distributed object database.

> And of course, the fundamental question, 'why is the syntax so clumsy and so wordy and
> why does there have to be so much repetition of the same info for the same thing?
>

Hopefully I answered this with the above.

BTW, I know you weren't asking for all these answers (check these, BTW, I
don't guarantee the accuracy of any of them ;-), but when I have the time I
like delving into this stuff. A lot of times some questions will make me
think of things in a way I hadn't had to before, or it might be a rationale
for something I've just glossed over, so formulating an answer helps to
educate myself as well.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Dec 5 14:15:52 2007