masarati@aero.polimi.it wrote:
In general, I also prefer to have NO matching rules associated to attrs designed for purposes that do not require matching
Why?
In general, configuring a system means to write something as a whole, not bit by bit, since it works as intended only when everything is in place. Changing a small bit can have unexpected semantic impact.
There are exceptions (either theoretically, or practically). For example, ACLs: occasionally one needs to tweak ACLs (in this case, small modifications can have tremendous impact on the functionality of totally unrelated parts as well), but ACLs need to evolve and adapt to needs. Another example are indexes. Nonetheless, I believe the best way to modify ACLs is through "replace". Fortunately, the most important aspect of ACLs is their order; in this case, the administrator can leverage the X-ORDERED feature.
For exceptions, and for all attrs that may legitimately need to be routinely modified, I concur having a well-defined matching rule is helpful.
As said it's useful for collision detection in case of a modify. So at least every multi-valued attribute should have an EQUALITY matching rule.
"replace" is your friend when managing configuration.
If in doubt which matching rule to use one could choose the stricter one as default, e.g. prefer caseExact over caseIgnore.
Well, I'm afraid there will always be someone complaining because we chose caseExact instead of caseIgnore.
Of course, my 2c.
p.