Subject: Attributes with no equality matching rule

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 27 Feb 2004 08:19:41 +0100

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 29 Feb 2004 16:15:11 +0900

Hmmm....  I'm not sure if we just missed 12.4.5, or what, but I do
think we likely do need to (re)consider whether the language in
[Models] is appropriate in face of this.

>Should the drafts conform to X.500 in this, or should they stay the

Well, given the RFC 2251's "MUST act in accordance with X.500"
language as well as the likely hood that multiple implementations
are acting in accordance with 12.4.5, I'm cannot see good reason
to adopt text (such as that in the current I-D) which is counter
12.4.5.

>like X.500?  Otherwise I think LDAP-X.500 gateways are in trouble.

I think it needs to be one way or the other. Otherwise clients
designed for one way won't interoperate properly with servers
designed for the other way.

Off hand, I think we need to revert to X.500 semantics unless
there is a very good reason to not to.  I don't see one.

Kurt