[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]



Hi Steven,

Steven Legg wrote:
Daniel Pluta wrote:
Please forget the additional syntaxes for now. In the meantime I've
learned that there is no possibility to support binary searching by
using an attribute of generalizedTime syntax within extensibleMatch
filters because ordering rules cannot be handled in extensibleMatching
rules because the specification does not say anything about ":<=" or ":>=".

I'm afraid you're under a misapprehension. Although the string representation of an extensible match contains a equals sign, it is just meaningless syntactic
fluff. The extensible match applies a matching rule, which is a boolean
predicate that may or may not represent a relational operator like "=".
So that the extensible match had the same expressive power as the other
filter items, the X.500 working group defined matching rules for each of
the syntaxes that has an obvious equality or ordering relationship between
values. For each syntax with an ordering relationship they defined two
predicates; an equality or "=" matching rule (e.g., generalizedTimeMatch)
and an ordering or "<" matching rule (e.g., generalizedTimeOrderingMatch).
This is sufficient to construct the other relational operators through an
expression of extensible match filter items. That is,

    "type=value" is (type:generalizedTimeMatch:=value)
    "type<value" is (type:generalizedTimeOrdering:=value)
"type<=value" is (|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value)) "type>value" is (!(|(type:generalizedTimeMatch:=value)(type:generalizedTimeOrdering:=value)))
    "type>=value" is (!(type:generalizedTimeOrdering:=value))

There is nothing magic about the choice of "=" and "<". The X.500 working
group could have chosen any other pair of the relational operators, or more than two, but this is the convention that has been followed since. Therein
also lies the reason why I suggested that currentTimeMatch and
currentTimeOrderingMatch were sufficient. It's not wrong to define more
rules as you have done, just unconventional and excess to requirements.

So it is possible to perform binary search on a syntax using extensible match given an ordering matching rule for that syntax, and it is meaningless to talk
about ":<=" or ":>=" with respect to the extensible match filter item.

This is just a short intermediate answer details regarding the other (main) points will follow later.

Many thanks for your explanation and the clarification that ordering matching rules in general are or should be supported, too.

We think we've been misled by a quick look into openldap's source where ordering matching rules (e.g. caseIgnoreOrderingMatch, generalizedTimeOrderingMatch) don't seem to be supported in combination with extensible match filter expressions:

Processing a filter like: (createTimestamp:generalizedTimeOrderingMatch:=2010...Z)
             results in "filter: (?=undefined)"

Sorry for the confusion and thanks again for the clarification.
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext