[Date Prev][Date Next]
Re: objectIdentifierMatch on ambiguous name
At 02:41 PM 1/3/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> 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.?
>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.
> Since a short name can refer to different OIDs in different
> contexts (e.g. there might be an object class 'x-fubar' and an
> attribute type 'x-fubar' in a subschema), a server SHOULD NOT
> allow short names in the OID syntax in contexts where it does
> not know which <numericoid> the short name represents.
Doesn't this contradict [Models, 1.3]?
> If the asserted value or attribute value is a short name of an OID,
> and the server does not know which <numericoid> the short name
> represents but allows such values as attribute values, the match
> evaluates to Undefiend, even if the asserted value and the attribute
> value are equal.
I'm thinking 4.3.26 of [Syntaxes] should say something like:
Servers SHOULD prevent values in <descr> form from be
stored in the directory for which the server is not
able to unambiguously determine which OID the <descr>
If the assertion value is presented in <descr> form and
the implementation is not able to determine which OID
the <descr> represents, the server SHOULD treat the
assertion as being Undefined.
That is, if the server cannot determine which OID the <descr>
refers to, the <descr> should be viewed as invalid.