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

[Daniel Pluta <[e-mail]>]

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.