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

Re: objectIdentifierMatch on ambiguous name



At 03:02 PM 1/20/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>>> How about?
>>>>         MatchingRuleIDs appearing in extensible filters?
>>>>         assertion values of attributeTypes, objectClasses, etc.?
>>>
>>>I think a general statement is better than listing instances.
>> 
>> While I certainly would prefer a general statement, I'm afraid
>> that different statements might be needed for different instances.
>
>I forgot to ask - why?

Because the existing specification stated a number of special cases...

>All syntaxes that use OIDs that I can see come
>with a definition which says which OID name space they apply to,

Really?  I think that most of the definitions of name space are actually
quite ambiguous.  Consider the assertion (objectClass=foo) in a subtree search
where different parts of the subtree are controlled by different
subschemas, each with a different definition for foo.  (Let's assume
the server holds the whole subtree for now.) Is the server to map foo
on a per entry basis, or once for the whole operation? 

>except
>the OID syntax itself - and the core schema only uses that for the
>objectClass attribute, which itself provides the namespace.

I think that an attribute type used in an attribute of a particular entry
may actually be insufficient to clear specify a namespace.  Consider DNs.
Are all names of attribute types appearing in a DN in the same name space,
or could each RDN be in a separate name space?