On Aug 26, 2008, at 10:45 AM, Michael Ströder wrote:
Kurt Zeilenga wrote:
An implementation can either publish the attribute description as specified (possibly with some additional names, extensions) or not. The description is otherwise immutable (per X.501). Note that publication of a schema description only indicates that the implementation is aware of the description. It does not necessarily mean that the server implements any particular functionality (other than the ability to publish schema descriptions).
...still we disagree on that. If consequently applied this paradigm would render the subschema subentry completely unusable for the client. IMO the subschema subentry SHOULD reflect what is effective on the server's side. Otherwise a client cannot find out what to do by looking at the schema.
I think you simply fail to realize that the subschema publication mechanism has limitations to its usefulness. As specified, it's simply not terribly usable as an implementation-supported-feature discovery mechanism. (When LDAP was being revised, I did suggest how it could become more useful, those suggestions were not supported by the consensus of the WG. Oh well.)
What you suggestion, I think, is quite problematic. Saying an attribute has no equality rule is not the same as saying a particular implementation doesn't support a particular rule. If a server where to say "this attribute has no equality rule", then others (clients or servers reading this) might not apply the equality rule even though they have implemented it. That might lead to very odd behavior.
I've somewhat solved my problem by also looking whether the referenced EQUALITY matching rule (here caseIgnoreListMatch) is listed in subschema subentry's attribute 'matchingRules'. But taking your wording literally even this wouldn't be guaranteed.
This seems no worse than taking a statement that an attribute has no equality rule to mean that attribute has an equality rule that is not implemented.
-- Kurt