Test the Search base before searching
04A Search has a base entry, a scope and a normal search filter. The assertion tests the base after it is found and before the search begins; it is not an extra filter applied independently to each candidate.
Both illustrated children have description=activity and match the ordinary filter. The base does not. These results do not mean an assertion was separately checked on each child.
Key idea: A failed base assertion returns no entries or continuation references.
Terms
- Base object
- The directory entry where this Search begins.
- Scope
- Which entries relative to the base the Search considers.
- Continuation reference
- A reference to another area relevant to the Search.
Rules & examples
A failed base assertion returns no entries or continuation references.
- For Search, the assertion target is the baseObject. RFC 4528 places evaluation after finding the base but before searching, using RFC 4511’s distinction.
- The first fixture has base ou=events,dc=example with description=busy. The assertion asks for description=ready, so it fails before traversing the subtree.
- If the base assertion is FALSE or Undefined, return 122 with no entries or continuation references. An existing, accessible base and an applied valid control are assumed; other finding/permission failures are not redefined.
- In a separate fixture, the base description is ready. The normal subtree filter (description=activity) selects the two illustrated children, not the base whose value is ready.
- The update/Compare atomic-action requirement is not a whole-Search snapshot guarantee. Do not infer that every candidate shares the base’s assertion or that later subtree contents cannot change.
Child labels are relative names under the displayed base. Their fictional description values are activity; omitted attributes/schema details are not a full directory dump. Search results shown are for this bounded fixture, not all possible Search results.
Sources
New to this? Start hereA quick picture + helpful background
Check the entry before changing it
Think of a shared directory card: a remembered value may be out of date by the time someone changes it. A conditional update asks the server to check the current card and perform the update as one action. This is an analogy for one operation, not a promise of a transaction across the whole directory.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.