Re: postalAddress matching rule
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