Re: objectIdentifierMatch on ambiguous name

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

At 05:55 AM 1/3/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>>  attribute type ( ... NAME 'oid'
>>>                   EQUALITY objectIdentifierMatch
>>>                   SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID
>> 
>> If this attribute is intended to hold OIDs referring to any
>> kind of object, then short names cannot be used with it.  That
>> is, the assertion (oid=foo) is Undefined.
>>
>> I note that if the attribute is intended to hold OIDs referring
>> to a specific kind of object (e.g., attribute types, object
>> classes, matching rules), the server needs also to be aware of
>> this intent in order to map "foo" to the appropriate (numeric)
>> OID.
>
>That seems a bit strict to me.  I think the filter (oid=foo)
>should match an oid attribute with value "foo", at least.

I don't think "foo" should be allowed as a value of 'oid'.
Because allowing "foo" allows "bar" and that requires there
to be a way for the server to determine whether "foo" and
"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.

Nor could "foo" and 1.2.3 be added to "oid" without whether
"foo" and 1.2.3 are equal.  The assertion (oid=1.2.3) is
likewise Undefined if "oid" contains the value "foo".

>Otherwise, if the admin wants to define an attribute which holds
>the names (descriptors) of attribute names, and the server doesn't
>provide an extension which lets him tell it which OID namespace
>the attribute uses, he must use Printable String syntax and
>caseIgnoreMatch instead of OID syntax and objectIdentifierMatch.

Yes.  That's exactly what the admin should do if he wants to
hold NAMEs.  Names in X.500 and, generally in LDAP, are just
printable stings which have no meaning except in a few limited
contexts.

Kurt