[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ORDERING rules vs. lessOrEqual filters
Hallvard,
Hallvard B Furuseth wrote:
> [Syntaxes] 5.2.7 and 5.2.11 say the -OrderingMatch matching rules
> evaluate to TRUE if and only if the attribute value is "less than"
> the assertion value.
>
> [Protocol] 4.5.1 says
> The matching rule and assertion syntax for greaterOrEqual and
> lessOrEqual filter items is defined by the ORDERING
> matching rule
> for the attribute type.
Strictly speaking, the assertion syntax for greaterOrEqual and lessOrEqual
is determined by the equality matching rule. The assertionValue in
AttributeValueAssertion is always an assertion value for the equality
matching rule of the type, thought it isn't necessarily the equality rule
that is applied. The protocol draft needs to be corrected.
>
> How? OK, a greaterOrEqual filter returns (not (result of the ORDERING
> matching rule)). But how is a lessOrEqual filter evaluated?
The obvious way, e.g. the filter
(cn<=foo)
is equivalent to:
(|(cn:caseIgnoreOrderingMatch:=foo)(cn:caseIgnoreMatch:=foo))
> Does it
> swap the assertion value and the attribute value,
In general, it is not possible to swap the assertion value and attribute
value since they may be of different syntaxes.
> or must ORDERING
> matching rules be implemented internally to return three values (less,
> equal, greater) in addition to Undefined?
An implementation is free to implement matching any way it wants as long
as it exhibits the correct external behaviour.
Regards,
Steven