[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?