[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Implementation of 4.5.2 and 4.5.3 of RFC 2251
> Does Open-LDAP server support the implementation of the "Search Result
> Reference" in Search operations as explained in 4.5.2 and 4.5.3 in the RFC
> 2251?.
Not yet, but I've volunteered to put it in.
> I know, for example, that in the NS Directory Server I can simulate the same
> behavior, as in the RFC, putting a
> Smart Referral in all the leaves entries but I think the point in the RFC is
> more on the way of a
> "knowledge reference", more exactly a "non-specific subordinate
> reference", as defined on the X.500 Recommendation.
>
> So on my opinion, It should exit an attribute in the administrative area
> (in a sub-entry), like the general referral, that in case that a user do a
> query with a "scope=subtree", the response message, if it is the case,
> indicates that this
> sub-tree continues in another or others servers without having to put a
> referral on all
> the leaves entries of the tree (like collective attribute in X.500).
I haven't seen any attribute like the one you describe. The closest is
the "ref" attribute which has yet to be published in an RFC or ITU
recommendation (although there is finally a draft that contains it).
The only other way that I have seen to get a SearchResultReference is
when dereferencing aliases.
Whether you get a SearchResultReference or a referral depends on whether
it's found when locating the base object or executing the search. If
it's for the base object, you get a referral, if it's found during the
search, you get a SearchResultReference. Note that aliases do not have
to match the search filter to result in a SearchResultReference. I'm
not sure if the same applies to "referral" entries since I haven't seen
anything stating this specifically, but I think
<http://search.ietf.org/internet-drafts/draft-ietf-ldapext-referral-00.txt>
comes close enough that it's safe to imply this behavior.
bob