Re: [ldapext] exclusions versus alreadySearched

[Mark Ennis <mark.ennis@adacel.com>]

Jim,

I seem to recall the main value of the ChainingResults.alreadySearched 
field occurs when processing a nonSpecificSubordinateReference (nssr). 
Each DSA referenced by the nssr will hold one or more subordinate naming 
 context under the nssr. The alreadySearched field in the 
ChainingResults allows the subordinate DSA to inform the superior DSA 
which subordinate naming contexts it holds and has provided results for 
in the chained search result. When using serial multi-chaining, this 
information can be passed on to subsequent subordinate DSAs through the 
ChainingArguments.exclusions field to reduce the work they need to carry 
out.

- Mark.

Jim Sermersheim wrote:
> All (especially anyone with X.500 experience)
>
> I'm trying to understand why the X.518 ChainingResults type has an
> alreadySearched field.
>
> If a DSA recieves a chained operation (which envelopes a search), and:
>
> - can service the entire search request, I see no need to report
> anything in the alreadySearched field.
> - returns a referral during name resolution, there is also no need
> - returns a referral while searching (equal to a search result
> referece), then the exclusions field of the referral holds the
> "alreadySearched" data.
>
> Thus I see no need for ChainingResults.alreadySearched. Am I missing
> something?
>
> Once I understand this and a few other isuues, I'll submit the chained
> operation I-D. I think I'll need to submit a control specification as
> well so we can start passing around information in the X.518
> ContinuationReference (like exclusions)
>
> Thanks,
> Jim
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext