Re: objectIdentifierMatch on ambiguous name

[Mark Wahl <Mark.Wahl@sun.com>]

> > 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'd tend to side with Kurt on this one though.  The 'at least' part is 
worrying.  I'd prefer to say that the server MUST support matching with 
a numericoid assertion value.  Perhaps it could be a server feature to 
have OID matching with short names.

> 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.

Or the admin could use an extensible matching rule with the OID syntax.

A similar issue is the objectIdentifierFirstComponentMatch MR for the 
attributes attributeTypes and objectClasses.  Should only 
numericoid be permitted in the search filter assertion value?  
If not, then it runs into the same difficulty as here.

Mark Wahl
Sun Microsystems Inc.