"Ennis, Mark" <mark.ennis@adacel.com> 6/22/04 7:24:08 PM >>>
<snip>
2) LDAP Servers often store a DN in the URI which represents
knowledge information (RFC 3296). This DN does not have to name the DSE
that holds the knowledge information. This can be useful (though
potentially dangerous) when mapping a local name to a different remote
name (let's call this "name mapping"). For example, I may have a server
that holds a subr DSE (well, a RFC 3296 referral) named
id=Sharks,id=MyStuff where the ref attribute holds a value
ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata.
I wouldn't clasify this as a good practice, but one that is allowed and
used. If we pass the local name of a reference's parent as the target
object (where that reference holds mapped names), it will surely cause
any validation check to fail (in fact it will cause the operation to
fail regardless of a validation check).
The target object of the chainingArgument is not the superior of the
subr DSE during name resolution.
I understand. I should have been more precise.
In the case of a named subordinate
reference as defined in RFC 3296, it looks to me like a combination of
an alias and a subordinate reference. I would re-write the target
object
by replacing the resolved portion with the name in the reference and
then chain the request to the indicated server, if I was following
X.518
procedures for distributed operation.
So you would re-write the target object as
"id=Sharks,order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata".
This wouldn't work, because the intent is that the name
id=Sharks,id=MyStuff on my server is the same as the name
order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata
on the remote server.