Subject: OID attribute values with unknown names

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 21 May 2004 22:49:26 +0200

[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 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).  That does not
seem to be the intent of rfc2252 section 6.25 (OID syntax).

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.

Otherwise, MAY the server refuse to store such names?  Maybe [Syntaxes]
or [Models] should answer that.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 25 May 2004 09:00:57 -0700

>>   or more non-negative integers that uniquely identify some object or

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.

>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

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.

>which resulted from the 'objectIdentifierMatch on ambiguous name' thread

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

---

From: Steven Legg <[email-masked]>
Date: Wed, 26 May 2004 17:21:34 +1000

Kurt,

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

> be viewed as representing) an OID.

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

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

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

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 26 May 2004 11:35:09 -0700

At 12:21 AM 5/26/2004, Steven Legg wrote:
>and the LDAP string encoding in the syntaxes draft.

For your information, the one instance initiated my bit of concern
was Directory String.
   A value of the Directory String syntax is a string of one or more
   arbitrary characters from the Universal Character Set (UCS) [UCS].

The abstract syntax is actually a sequence of arbitrary characters,
commonly of UCS but could be of T.61 or other character sets.  The
restriction to UCS is peculiarity of the LDAP string encoding, not
of the abstract syntax.

However, after toying around with some alternative wordings, I
couldn't come up with anything better.  So I'm fine with letting
this be.

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

Yes.  Overall, I think [Syntaxes] is quite clear and "good enough".
Regardless of what we do, there will be some odd readings.

Kurt

---

From: Steven Legg <[email-masked]>
Date: Thu, 27 May 2004 16:42:46 +1000

Kurt,

> restriction to UCS is peculiarity of the LDAP string encoding, not

Since we talk about transliterating T.61 to UCS to do matching in the
directory (LDAP and X.500), and since XER, RXER and GSER all depend on
a notion of equivalence between T.61 characters and UCS characters,
one could almost make the case that the different ASN.1 string types
are just different ways to encode UCS characters :-) .

> couldn't come up with anything better.

Me neither. I decided that being pedantic on this wouldn't be
helpful to the reader since the choice of character encoding carries
no semantic weight in LDAP or X.500, and most LDAP users will never see
that it makes any difference.

 > So I'm fine with letting

Okay.

Regards,
Steven