It's my view that matchedDN can be returned anytime its useful,
regardless of what the resultCode might be. The value indicates
the most-subordinate object used in finding the target/base
object. It can even be useful when the resultCode is success
(consider aliases/cross-references/etc.).
At 03:00 PM 8/17/2005, Pierangelo Masarati wrote:
I note that now back-ldap, as a consequence of retaining anything comes from ldap_parse_result(), in case it hits a referral it returns bot the ref and the matchedDN. For example, in test039, there is a referral entry "cn=Somewhere,ou=Meta,o=Example,c=US". According to draft-ietf-ldapbis-protocol, the matchedDN can should be returned with some specific errors, but could be returned also with other errors/return codes, I guess including referral return codes. When searching for, e.g. "cn=Deeper,cn=Somewhere,ou=Meta,o=Example,c=US", back-ldap returns a matchedDN="cn=Somewhere,ou=Meta,o=Example,c=US" and a ref="ldap:///cn=Deeper,cn=Somewhere,ou=Meta,o=Example,c=US";. In this case, the matchedDN might make sense, because the ref indicates how to continue the operation, while the matchedDN indicates what portion of the DN was present locally. But when searching exactly for "cn=Somewhere,ou=Meta,o=Example,c=US" one gets both matchedDN="cn=Somewhere,ou=Meta,o=Example,c=US" and!
ref="
ldap:///cn=Somewhere,ou=Meta,o=Example,c=US";. I suspect in this latter case the matchedDN is definitely redundant.
No, because it advises the client that the server had specific
knowledge at cn=Somewhere,ou=Meta,o=Example,c=US. WIthout this,
the client might think the referral was due to global knowledge.
Should it be trimmed?
No.