Re: OID attribute values with unknown names

[Steven Legg <steven.legg@adacel.com.au>]

Kurt,

Kurt D. Zeilenga wrote:
> 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).

I would say that the abstract data type is "the syntax".
The representation in LDAP (in protocol messages) is an encoding
for the syntax.

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

A short name can also be said to be an encoding of the OID
abstract value.

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

I have been very careful in making a distinction between the abstract syntax
and the LDAP string encoding in the syntaxes draft. Firstly, section 3.1
makes the point that the encodings are something distinct from the
syntax, and that multiple encodings exist:

   The description of each syntax specifies how attribute or assertion
   values conforming to the syntax are to be represented when transferred
   in the LDAP protocol [PROT]. This representation is referred to as
   the LDAP-specific encoding to distinguish it from other methods of
   encoding attribute values (e.g., the Basic Encoding Rules (BER)
   encoding used by X.500 [X.500] directories).

Each syntax description starts by describing the syntax in abstract terms:

   A value of the Foo syntax is ...

without reference to any particular protocol representation. That description
is then followed by a description of the encoding used by LDAP (which is
explicitly called out as being LDAP-specific):

  The LDAP-specific encoding of a value of this syntax is ...

> instead of in terms of the
> underlying ASN.1 data type (which the LDAP
> string encoding is just one of many possible
> representations of).

The underlying ASN.1 type is mentioned in each syntax description but I
didn't put that up front because when you get right down to it, X.680
doesn't actually tell you what abstract syntaxes really are. Deferring
to ASN.1 isn't going to help the average punter to understand what
attribute syntaxes in LDAP are all about.

> This may be part of the
> problem.

Or they are reading their own assumptions into what is actually written.

Regards,
Steven

> Kurt