RE: searching multiple backends

["Howard Chu" <hyc@highlandsun.com>]

> "Howard Chu" <hyc@highlandsun.com> writes:
>
> > You stated that the directory layout I described was bogus.
>
> Absolutely not.  I said that if your X.500 DSA masters o=bar, it
> cannot go asking somewhere else asking for a list of things directly
> under o=bar and that doing *this* was bogus.  It *has* to know *what*
> things are below (and since you brought up DNS, that's exactly how DNS
> works).  If it knows that such and such things are mastered somewhere
> else, then these are separate namingContexts.

There is a difference between knowing that an entry exists, and knowing the
contents of the entry. Knowing about the existence of an entry is a
"knowledge reference" in X.500. The similar concept exists in DNS - again, a
superior DNS server does not contain all of the contents of its subordinate
entries. It just contains references to the subordinate servers that master
those entries.

In X.500 the LIST operation allows one to query all of the names of the
entries immediately below a particular node. This request can be satisfied
completely in the scenario I first described, without chaining anything. In
LDAP there is no LIST operation; it must be emulated with a OneLevel SEARCH.
However, a Search must return the contents of an entry, not just the fact of
the entry's existence. In this case, the X.500 DSA must chain the Search
request down to the subordinate DSA.

> Later I showed with
> spec that, beyond my personal opinion, this is exactly what is
> supposed to happen.  Unless the spec changes, your X.500 DSA has to
> make separate searches for each delegated naming context.  Because an
> LDAP server conformant to the spec is going to return a referral error
> result if an attempt to search all of them in the same request is
> tried.

Your interpretation of the LDAP RFC is suspect. Section 3.3 of RFC2251
explicitly states "An LDAP server MUST act in accordance with the
X.500(1993) series of ITU recommendations when providing the service."

Section 19.3 of X.501 also states:
	It is possible for a master DSA's administrator to have
	administrative authority for several disjoint naming contexts. For
	every naming context for which a master DSA has administrative
	authority, it shall logically hold the sequence of RDNs which lead
	from the root of the DIT to the initial vertex of the subtree
	comprising the naming context. This sequence of RDNs is called the
	context prefix of the naming context.

As such, an LDAP server configured for ou=foo,o=bar MUST also implicitly
recognize o=bar. In this case, the clause you quoted from section 4.5.3 of
RFC2251 doesn't really apply, because the server SHOULD have located the
base object that was specified.

This also answers one of the problems Kurt brought up with verifying DIT
correctness when gluing contexts together.
  -- Howard