Subject: [ldapext] exclusions versus alreadySearched

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 11 Jun 2004 17:47:50 -0600

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Mark Ennis <[email-masked]>
Date: Tue, 15 Jun 2004 09:08:36 +1000

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.