[Date Prev][Date Next] [Chronological] [Thread] [Top]

Attributes with no equality matching rule



I've just gotten a major surprise from looking at X.500(1993):

Attributes with no equality matching rule are rather special in
X.500, but not very in old LDAPv3 and even less so in LDAPbis' LDAP.
(Partly because of my suggestions, I'm afraid...)

Should the drafts conform to X.500 in this, or should they stay the
way they are?

Or - maybe implementations SHOULD behave as stated today, but MAY behave
like X.500?  Otherwise I think LDAP-X.500 gateways are in trouble.

Anyway, here are the specifics.  X.501(1993) says:

   12.4.4   Attribute syntax

   If an equality matching rule is specified for the attribute type,
   the Directory shall ensure that the correct attributesyntax is
   used for every value of this attribute type.

   12.4.5   Matching rules
   (...)
   If no equality matching rule is indicated, the Directory:
   a) treats values of this attribute as having type ANY, i.e. the
      Directory may not check that those values conform with the
      data type or any other rule indicated for the attribute;
   b) does not permit the attribute to be used for naming;
   c) does not allow individual values of multi-valued attributes to
      be added or removed;
   d) does not perform comparisons of values of the attribute;
   e) will not attempt to evaluate AVAs using values of such an
      attribute type.

12.4.4 and 12.4.5a really surprised me.  Are they really saying that
the server must allow the user to store a DN in the telexNumber
attribute, since telexNumber has no equality matching rule?

I believe LDAP, for attributes without EQUALITY matching rule:

   a) checks attribute syntaxes, unlike X.500.

   b) partly mimics X.500:

      As far as I can tell, there is no statement forbidding RDN
      components without equality matching rules.
.
      OTOH, DNs are _matched_ according to the RDN components' equality
      matching rules ([Syntaxes] 4.2.10. distinguishedNameMatch), so if
      a DN contains an attribute without an equality matching rule,
      presumably one cannot retrieve that entry by its name.  One can
      retrieve it by searching for it, though.

   c) does allow us to add/remove individual values, unlike X.500.

   d) mimics X.500:
      does not perform comparisons of values of the attribute.

I'm not sure what (e) implies, so I'll let others comment on that.

X.500(1993) can be read at <http://archive.dante.net/np/ds/osi.html>.

(Sorry, I won't see answers until after IETF#59; I'm about to go on
vacation.)

-- 
Hallvard