> Daniel schrieb: > >> masarati(a)aero.polimi.it schrieb: >> >>>> What kind of alternative solutions exist or do you see? >>>> >>> I'd rather define a new ordering matching rule for time-valued attrs >>> that >>> checks how a given value compares with "now"; something like >>> "greaterThanNow" and "lessThanNow". This would allow to do something >>> like >>> >>> access to attrs=validnow val/greaterThanNow=19700101000000Z >>> >>> or >>> >>> access to filter=(validnow:greaterThanNow:=19700101000000Z) >>> >>> where 19700101000000Z (the epoch) is used as a placeholder for the >>> asserted value, which would be ignored. >>> > After some experiments with MRs I think that I have not understood your > suggestion the right way or your suggestion is misleading... > > In case the two new MRs "earlierThanNow" and "laterThanNow" are new > ORDERING MRs they have to be compared using lt- or gt-operators, haven't > they? > No, you need to use an extensible filter, which is sort of a generalized assertion. What you use is "attr:mr:=value". Then, it's the purpose of "mr", your custom matching rule, to perform something that is equivalent to an ordering match. Your attributes do not need to have anything special about matching rules. They could even have no matching rule defined. All they need is to have "generalizedTime" syntax, so that your custom matching rule can be applied.

> From the results of my MR-tests I think I should/could: > 1. define ORDERING using "generalizedTimeOrderingMatch" (to make > standard LE/GE ldapsearch filtering using "<=" and ">=" work out of the > box) > That makes sense, although it would be orthogonal to using the earlierThanNow/laterThanNow rules through extensible filters.

> 2. use the two additional MRs on-demand (replacing the above "default" > ORDERING by the new ones), e.g.: > (validNotBefore:earlierThanNow:<epoch) or/and > (validNotBefore:earlierThanNow:>epoch) > The above string representations do not conform to LDAP search filters. See RFC 4515 for a definition of extensible match.