[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: searching multiple backends
> "Howard Chu" <hyc@highlandsun.com> writes:
> ... 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.
>
> In a different message you propose a glue entry and quickly hit the
> referral loop problem and ask for slapd to break again the spec by not
> returning the SearchResultReference entries (this is wrong, read 6.2
> in RFC2251 where responsiblity for avoiding referral loops is placed
> with the clients).
These RFCs really are what they say "Request For Comments" - they are not
cast in stone and until they graduate to formal Standard status, nobody
expects them to be absolutely correct or comprehensive. Section 6.2 states
that clients *must* detect loops, but does not state that servers *must not*
detect loops. There is nothing wrong with my proposal for loop avoidance; it
violates no specs. It is in fact encouraged in X.518 section 15.4: "Loop
detection is mandatory and loop avoidance is optional."
Section 6 of RFC2251 is understandably short. Since the LDAP standard is
only the specification for a particular interface to an X.500 directory
system, and the complete directory system is spelled out in the ITU
standards, one is intended to fill in the blanks of the RFCs with the ITU
specifications, just as RFC2251 makes direct reference to X.511 at multiple
points.
Unfortunately LDAP is really only suitable as a client access protocol and
not a server-to-server protocol. As such, when contemplating chaining in the
LDAP world, it is impossible for a LDAP server to detect loops, and avoiding
loops is only possible in the simplest of circumstances.
> No, your example talks about:
>
> #1 ou=foo,o=bar
> #2 ou=baz,o=bar
> #3 ou=fiz,o=bar
>
> Unless there is also
>
> #n o=bar
>
> mastered by that server, it should fail per the spec. But if it
> really were there, it seems it would fail too and that should not
> happen, *this* is the bug.
Yes. We agree perfectly here. Now if only we could agree on a solution.
-- Howard