Re: objectIdentifierMatch on ambiguous name

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:49 AM 1/3/2003, Mark Wahl wrote:
>"Kurt D. Zeilenga" wrote:
>> "bar" are equal or not.  However, the implementation has
>> no knowledge of which mapping table, or which subset of
>> a table, of short names to numeric oids applies; the question
>> of whether "foo" is equal to "bar" is, without context,
>> Undefined.
>
>Common practice for LDAPv3 servers though is to support queries of 
>the form (objectClass=person),

Of course, this is "with context".  objectClass is part of
the system schema (despite being of usage userApplications)
hence the server knows its values refer to object classes.

If non-standard object classes are used,  there is some
ambiguity as to which subschema should be used to map value
to an OID.  I assume most implementations use the subschema
controlling the entry named by the baseObject and don't
allow the same name to kind of element (object class, attribute
type, matching rule) to appear in a subschema.

>and many clients today use objectClass equality matching with non-numeric OIDs.

I prefer to use the term 'OID in <descr> form'.  The key is that
matching is done on abstract value, in this case, OIDs. 

>2252 section 8.1 only said the match was Undefined if the server did not recognize the OID.

This statement:
   If the client supplies a filter using an objectIdentifierMatch whose
   matchValue oid is in the "descr" form, and the oid is not recognized
   by the server, then the filter is Undefined.

is somewhat problematic (because <descr> are ambigious).  I think
a server should be free to treat the match as Undefined when there
is insufficient context to determine whether the assertion value
matches an entry (per RFC 2251, 4.5.1).

In short, I think we need to be clear as when <descr> form SHOULD
be used and when it SHOULD NOT be used.  I think we all agree that,
in LDAP, they SHOULD be used for AttributeTypes appearing in the
protocol, values (and assertion values) of the objectClass attribute,
and in <oid> productions appearing in schema descriptions.

How about?
        MatchingRuleIDs appearing in extensible filters?
        assertion values of attributeTypes, objectClasses, etc.?

Kurt