Subject: [ldapext] subtree search with glue entries

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 09 Jun 2004 09:11:38 -0600

All,

Assume a server populated with these entries:

dc=com (glue)
dc=example,dc=com (context prefix)
dc=org (context prefix)

When a one-level or subtree search is rooted at the DIT root (empty RDN
sequence)*, how should dc=com be treated?

1.1) It should not be returned
1.2) A search result reference should be generated using the superior
referral should be returned

When a subtree search is rooted at the DIT root (empty RDN sequence)*,
how should dc=example,dc=com (and subordinates) be treated?

2.1) They should not be returned
2.2) They should be returned

I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else
have experience here?

Jim

*Note that while some LDAP servers don't support this, it is a feature
of X.511

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 09 Jun 2004 09:34:24 -0700

>referral should be returned

I would argue that since server does not hold the baseObject of the
search, it should return a referral to the server which holds it.
That server, in response to the client's search, return any objects
it holds in scope and a continuation back to this server for
dc=example,dc=com with an appropriate scope: baseObject (if original
scope was one-level) or subtree (if original scope was oneLevel).

>how should dc=example,dc=com (and subordinates) be treated?

The server should refer the client (using a search referral) to
a server which has superior knowledge.

>I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else

Yes.  In OpenLDAP, one can configure a server to have root knowledge.
That is, to have knowledge of where all top-level naming contexts
are held.  The OpenLDAP Root Service [RFC3088] operates in this manner.

>*Note that while some LDAP servers don't support this, it is a feature

In LDAP, a number of implementations (including OpenLDAP, if so (mis)configured)
will treat a non-baseObject scoped search at the root ("") as a like-scoped
search at a context prefix held by the server.  The idea, I guess, is to
"friendly" or, more specifically, to avoid client configuration of an
appropriate search base (or implementation of namingContext/enhancedSearchGuide
discovery).

Because of this, it makes build any kind of "global" directory quite
difficult.  (There are, of course, other reasons why building "global"
directories is difficult.)

Kurt