Re: (ITS#6247)

[daniel@pluta.biz]

masarati@aero.polimi.it wrote:
>> 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.
>   
I've already thought about this. I'm in two minds about that.

> 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.
>   
I thought, that by not assigning any matching rule the EQ/LE/GE 
comparison is not possible at all. That's the behavior I would like to 
achieve regarding the two minimum-attributes (regardless whether the 
probable separation of matching rules and attribute definitions - 
disscussed in the above paragraphs).

Yesterday I've noticed that without an EQ-Matching definition I was not 
able to add an additional value in case of a multi-valued attribute 
definition (so I added EQ-Matching again). I have to admit that I do not 
understand this in detail. I also have not investigated in deep...

> 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).
>   
The oc/attr definition is for demonstration purposes only (I though it's 
more compact to include this "demo" and implement it the most restricted 
way regard data privacy (especially disallow querying LE/GE for both attr).
Problably I'll separate the demo into an extra schema file.

> 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
>   
hehe that relativistic effects I already had in mind before implementing 
this kind of matching rule. That's the reason I originally followed the 
approach to manipulate the search requests' filters. This approach could 
assure to make use of the "same" now (op->o_time) for all entries.

By using the matching rule (especially in combination with the filter= 
statement in ACLs) "now" will become some kind of "time distance" 
instead of a point in time because a search' results get evaluated 
sequentially by test_filter().

In worst case the second have of a billion search entries are valid 
during the search but get "invalid" during acl processing, because time 
move's on... ;-)

On the other side comparing the lines of code of the matching rule 
approach to my previous pre-alpha overlay's lines of code, this matching 
rule's implementation is about 10 times smaller...

> 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.
>   
Ok, this in mind I'll at least reduce the matching rules to two but the 
problem (now == time_delta) still exists.
> 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.
>   
I regard to some kind of future formal specification I thought about 
this, too: in my opinion it seems to be "unnatural" to search (assert) a 
non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But 
probably that's really only a matter of style.

> 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.
>   
I'm currently thinking about this...

Thanks for your feedback the discussion is very interesting and helpful.