Re: postalAddress matching rule

["Brett @Google" <brett.maxfield@gmail.com>]

> I don't want to hold you back from implementing the EQUALITY matching rule
> for PostalAdress syntax.
>
> But you could also just delete the whole attribute and re-add the value(s)
> needed. (That's how the delta-modification works in web2ldap if the EQUALITY
> matching rule is not implemented.)

Yes that's what i did to fix my test data, but specifically this
change was made indirectly by the collect.c overlay, not manually by
me, which populates attributes from a parent or template object
through to all the children of that object. I want to use the collect
overlay to make child objects have the same postalAddress (amoung
other attributes) of some parent or template object, such as some
superior ou entry that is component of the user's dn.

This issue arises as to what happens to when you try to edit
postalAddress in a child object which has collected an attribute from
some parent, what is presently happening is that the parent gets
another duplicate attribute value on the inherited attribute. In other
words it allows the change, but it cannot tell that the new attribute
value is the same as the old attribute value.

While this is probably a bug that needs fixing, i'm considering the
best option for a workaround.

While this probably can be simply fixed by disallowing writes on
attributes of child object which are collect-ed from a parent, my
thought was that if there was an equality matching rule and it were
implemented, the update would fail or silently ignore the update (as
ldap would normally) because the attribute already has that value, and
it would be a tidier / more correct solution.

To paraphrase, i'd prefer to leave the decision as to whether the
attribute MAY be written, to the access control system, and just work
on the fact wether the attribute should be written (ie. it already has
that value, so request should be silently ignored or errored, i favour
the former) which is more correct IMHO, just disabling writes is
ignoring the problem (although that also might be a nice feature).

Cheers
Brett