Daniel schrieb:

...

masarati@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.

This leads me to the question why are there two MRs needed if the operator could be used to tell the difference... (e.g. earlierThanNow: "<" and laterThanNow: ">")?

Because you need two separate assertions for earlierThanNow and laterThanNow.

Another question concerns the schema-definition of the two dead-end attributes "validNotBefore" and "validNotAfter": In my current definition both are of type "generalizedTime", EQUALITY is "generalizedTimeMatch" but what should I use for ORDERING?

See above. Nothing is needed about equality.

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.

Would this be possible or ok? What alternatives do you possibly see or suggest?

Stick with the original plan, implement it correctly.

p.