Re: (ITS#6247)

[masarati@aero.polimi.it]

> Hi,
>
> I've just uploaded an updated version.
>
> Changes regarding schema:
> - Added EQ-Matching rule to both nowNot{Before|After} attributes
> - changed attribute nowNotAfter from single- into multi-value
>
> ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz

In order to make your contribution useful to others, I think you should
definitely separate comparison with respect to current time from the rest
of what you need.

In this sense, special matching rules to compare generalizedTime-syntax
attributes with respect to "now" have nothing to do with the declaration
of specific generalizedTime-valued attributes.

As I mentioned in an earlier posting, any generalizedTime-syntax attribute
can use your special matching rules by way of the extensible filter
mechanism, regardless of having any matching rule in their definition.

Moreover, attributes can already be defined using slapd.conf/back-config,
so there's no need to hardcode them in your module (except, possibly, for
your specific needs, but this makes the module less general and useful to
others).

Finally, I don't think having both a "(<)" and a "(<=)" rule makes sense. 
LDAP only defines "(<=)" since one may construct "<" as "(!(>=))".  But
the real reason is that "exactly equal to now" makes little sense as "now"
is evanescent: you have no control about exactly when your matching rule
will be evaluated, so if the difference between "including now" or
"excluding now" is crucial, then there might be something flawed in the
policy you're trying to implement.

Getting more into implementation related aspects, I think you should
really ignore the asserted value, rather than check it's equal to the
Epoch.  I initially suggested to put the Epoch as the asserted value in
order to use some clearly recognizable, yet valid, value.  But this should
be a matter of style rather than a requirement of the matching rule.

With respect to OID assignment, as soon as your contribution is considered
of general usefulness, it could receive a temporary OID out of OpenLDAP's
experimental branch.  If you intend to formalize this set of matching
rules somehow, you should apply for IANA assignment of an official OID. 
Note that I'm not encouraging nor discouraging you in this sense.

p.