Subject: [ldapext] superior of subrDSE while chaining a resolved operation

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 20:17:49 -0600

>>> "Ennis, Mark" <[email-masked]> 6/22/04 7:24:08 PM >>>
<snip>
>If I remember correctly, the argument for using the name of the
superior 
>of the subr DSE is so that multiple sibling subr DSEs, where the 
>subordinate entries are in the same subordinate DSA, will result in a

>single continuation reference instead of one for each sibling, thereby

>reducing the number of chained operations required to complete the 
>operation. 

I see (after reading a bit of the X.518 Continuation Reference
procedures). This helps the case you mention, but gives rise to the case
where each sibling subr DSE points to a different DSA. If each of those
DSAs holds copies of the naming contexts of the others (those named by
the other sibling subr DSEs), then the exclusions field must be used to
ensure that duplicates aren't returned.

>It also makes the subr and nssr reference types generate 
>equivalent continuation references. This may be another reason for the

>ChainingResults.alreadySearched field.

Yes.

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

---

From: "Ennis, Mark" <[email-masked]>
Date: Wed, 23 Jun 2004 12:28:27 +1000

> ensure that duplicates aren't returned.

Either exclusions or dontUseCopy.