Re: (ITS#6247)

[masarati@aero.polimi.it]

> masarati@aero.polimi.it wrote:

>> 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).

By not assigning a matching rule, that specific matching is not possible
using normal filters.  However, the extensible filter mechanism overrides
this, by allowing to specify the desired matching rule in the AVA.

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

That's a totally different business.  If you do not define an equality
matching rule, multiple values cannot be checked for duplicates.  So the
only way to add a value consists in performing a modify:delete and a
modify:add within the same modify operation that removes the original
values and replaces them with themselves plus the new ones.

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

You should.  Please note that for the purpose of testing your code, every
entry already has a createTimestamp and a modifyTimestamp attribute.

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

Well, this calls for an extension of the matching API that also passes the
Operation pointer.  Something for 2.5, if worth the effort (note that
value matching and operations are orthogonal, as value matching can also
occur outside the scope of a LDAP operation, so passing that pointer would
basically be a matter of opportunity if matching rule implementations need
it).

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

If you follow my advice, it'll be 100 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.

I concur.

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

I'm not sure I understand what you mean here.  If you mean that anything
could fit as the asserted value, this is not correct, because LDAP
requires the asserted value to comply with the syntax of the matchingRule.
 Of course one could define a syntax for asserting generalizedTime values
that consists in the empty string, so that
(createTimestamp:laterThanNow:=) is a valid filter (note the empty
asserted value).

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

p.