Group conditions before matching
02Prefix operators join complete filters; LDAP evaluation also has an Undefined result.
NOT applied to an Undefined child remains Undefined. The entry is ignored, not selected by the negation.
Source for this drawing: RFC 4515 · Read RFC source: RFC4511 §4.5.1.7 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
& means AND, | means OR, and ! means NOT. Each operator comes before its child filters. AND and OR require one or more children; NOT has exactly one.
- & means AND, | means OR, and ! means NOT. Each operator comes before its child filters. AND and OR require one or more children; NOT has exactly one.
- LDAP servers MUST use three-valued evaluation: AND is FALSE if any child is FALSE, otherwise TRUE if all are TRUE, otherwise Undefined. OR is TRUE if any is TRUE, otherwise FALSE if all are FALSE, otherwise Undefined.
- NOT swaps TRUE and FALSE but leaves Undefined unchanged. Only TRUE selects an entry, subject to access controls. Unrecognized attribute or matching-rule identifiers can yield Undefined. RFC4511 says servers MUST NOT return errors for unrecognized filter attributes/rules, invalid assertion values or unsupported assertion syntax; malformed filter strings are a different case.
RFC4515 §3 defines the string grouping; RFC4511 §4.5.1.7 defines its evaluation. An absent attribute and an unrecognized attribute are not interchangeable. No generic JavaScript string comparison is used as an LDAP matching rule.
Read the RFC section ↗