Discover support and choose criticality
05The root DSE is the server-information entry. It can advertise supported request controls. Criticality tells the server whether the client accepts running the operation without a control it cannot or will not apply.
Now the server can and will apply the control. Critical FALSE plus a FALSE assertion still returns 122 and leaves busy unchanged.
Key idea: TRUE forbids unguarded processing; FALSE does not weaken an assertion that is actually applied.
Terms
- Root DSE
- The server’s information entry (DSE means DSA-specific Entry; DSA is Directory System Agent).
- Criticality
- Whether performing the request without the control is unacceptable.
- supportedControl
- A root-DSE attribute listing supported request-control identifiers.
Rules & examples
TRUE forbids unguarded processing; FALSE does not weaken an assertion that is actually applied.
- Servers implementing RFC 4528 SHOULD publish 1.3.6.1.1.12 in rootDSE supportedControl. They MAY advertise it only when the client is authorized. Absence alone is therefore not proof of non-support.
- RFC 4528 permits criticality TRUE or FALSE; it does not mandate TRUE for every request. Choose TRUE when the client cannot accept the operation without this protection.
- For the illustrated Modify, if the server cannot or will not apply the control and criticality is TRUE, RFC 4511 §4.1.11 requires no operation and unavailableCriticalExtension(12).
- For that unsupported/unwilling case with criticality FALSE, the control MUST be ignored. Normal processing may then perform an unguarded update; success is only the chosen example, not guaranteed.
- If the server applies the control, it applies it consistently regardless of criticality. A FALSE or Undefined assertion still returns 122 even when criticality is FALSE. These examples are Modify requests with responses, not rules inventing responses for Abandon/Unbind.
The unsupported example is explicitly configured as unable/unwilling; it is not inferred from an omitted advertisement. This control’s discovery entry is distinct from the application entry being modified. No automatic fallback retry is recommended.
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.