Re: OID attribute values with unknown names

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

At 01:49 PM 5/21/2004, Hallvard B Furuseth wrote:
>[Syntaxes] 3.3.26 (OID) says:
>
>>   A value of the OID syntax is an object identifier; a sequence of two
>>   or more non-negative integers that uniquely identify some object or
>>   item of specification.

This is a description of the abstract data type 'object identifier,
not a description of its representation in LDAP (the syntax).

A short name (descriptor) is not an OID, it refers to (or can
be viewed as representing) an OID.

>This seems to imply that the server MUST NOT store a name in an OID
>attribute unless it knows which numericoid the name represents (and
>therefore also knows what kind of OID the attribute values represent -
>e.g. object classes, matching rules, or whatever).

Unless the server knows which abstract value the transferred value
represents, the server cannot do much with it.  With numericoid,
the abstract value represented is obvious.  With short names,
the abstract value represented requires other knowledge.

>That does not
>seem to be the intent of rfc2252 section 6.25 (OID syntax).

The intent of RFC 2252 was simply to allow transfer of either
representation.  It said little about the need for the server
to understand which abstract value the transferred value
represented.

>The rest of the section does allow for names, but it says nothing about
>unknown names, so it doesn't seem to override the text above:
>
>>                           Many of the object identifiers used in LDAP
>>   also have IANA registered names [RFC3383].
>>
>>   The LDAP-specific encoding of a value of this syntax is defined by
>>   the <oid> rule in [MODELS].
>
>If the above restriction is intentional, we can remove some of the text
>which resulted from the 'objectIdentifierMatch on ambiguous name' thread
>in 2003.

The key here is that matching is defined in terms of abstract
values, not how they might be represented.  If the representation
of either the asserted value or stored value is ambiguous, then
the match should be Undefined.

>Otherwise, MAY the server refuse to store such names?

The server is to store an OID (in a representation of its
choosing).  If the transferred name does not convey(*)
unambiguously which OID to store, the server should not
attempt to store an OID (because it doesn't know which OID
to store).

>Maybe [Syntaxes] or [Models] should answer that.

What I describe above seems more of a [Protocol]
(Section 4.1.5) issue than a [Models] or [Syntaxes]
issue (but...).

(*) in the server's eye.  If we consider other syntaxes,
such as directory string, the client has no clue as
to which CHOICE the value "foo" conveys.  A CHOICE
printableString "foo" is a different abstract
value than CHOICE universalString "foo", they are
are equivalent.

I note that this as it implies we would need to be
very careful in adding a general clarification in
[Protocol].  Addressing this in [Syntaxes] may be
more appropriate.

In reading [Syntaxes] again, I am a bit concerned
that it describes syntaxes in terms of the LDAP
string encoding instead of in terms of the
underlying ASN.1 data type (which the LDAP
string encoding is just one of many possible
representations of).  This may be part of the
problem.

Kurt