Subject: draft-ietf-ldapbis-syntaxes-02: oid = descr / numericoid

From: Michael Ströder <[email-masked]>
Date: Sun, 01 Sep 2002 15:44:33 +0200

HI!

I'd like to propose a change to draft-ietf-ldapbis-syntaxes-02 since I 
noticed some problems with same OID textual descriptions being used for 
object classes and attribute types.

Current text:

------------------------------ snip ----------------------------
    When 'oid' elements occur in a value, the 'descr' notation option
    SHOULD be used in preference to the 'numericoid'.  An object
    descriptor is more readable than a numeric OBJECT IDENTIFIER, and a
    descriptor (where assigned and known by the implementation) SHOULD
    be used in preference to numeric oids to the greatest extent
    possible.  Examples of object descriptors in LDAP are attribute
    type, object class, and matching rule names.

       oid = descr / numericoid

------------------------------ snip ----------------------------

IMHO the other way round is better since it causes less grief on side of 
a schema-aware application:

    When 'oid' elements occur in a value, the 'numericoid' notation
    option SHOULD be used in preference to the 'descr'. An object
    descriptor might be ambigously used
    to specify an attribute type, an object class or a matching rule
    name.

Please excuse my poor English.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 01 Sep 2002 08:23:33 -0700

I note that these productions has been moved to
draft-ietf-ldapbis-models, Section 1.3 (Common
Productions).   ldapbis-models also contains
a section, 6.2, which briefly discusses
"Short Names".  Please review.

Kurt

At 06:44 AM 2002-09-01, Michael Ströder wrote:
>HI!
>
>I'd like to propose a change to draft-ietf-ldapbis-syntaxes-02 since I noticed some problems with same OID textual descriptions being used for object classes and attribute types.
>
>Current text:
>
>IMHO the other way round is better since it causes less grief on side of a schema-aware application:
>

---

From: Michael Ströder <[email-masked]>
Date: Sun, 01 Sep 2002 17:45:01 +0200

Kurt D. Zeilenga wrote:
> Productions).

Same issue in draft-ietf-ldapbis-models-02:

------------------------------ snip ----------------------------
   Short names, known as descriptors, are used as a more readable aliases
   for object identifiers.  Descriptors are case insensitive and conform
   to the the ABNF:

       descr = keystring

   Where either an object identifier or a short name may be specified,
   the following production is used:

       oid = descr / numericoid

   The <descr> form is preferred.  When a production <oid> is encoded in
   a value, the <descr> encoding option SHOULD be used instead of the
   <numericoid> encoding option.
------------------------------ snip ----------------------------

I also wonder how to implement 'objectIdentifierMatch' (2.5.13.0) for 
syntax 1.3.6.1.4.1.1466.115.121.1.38 ('OID').

 >   ldapbis-models also contains

------------------------------ snip ----------------------------
6.2. Short Names

   Short names (descriptors) used to identify various schema elements are
   non-unique, as two different specifications (neither in Standards
   Track RFCs) may choose the same name.  The client can retrieve the
   subschema (as described above) to determine the element identified (in
   that subschema) by a particular short name.
------------------------------ snip ----------------------------

Again the magic phrase "the client can retrieve the subschema" is used.

I can name you at least one existing LDAP server implementation where 
the same short name is used for an attribute type *and* an object class 
in the subschema. This was the reason why I introduced another level of 
mapping in the name2oid translation table of python-ldap's schema 
module. Otherwise it did not work.

AFAIK there's no LDAP client which can do things like this for each and 
every situation where you have to do some sort of name2oid resolving. 
 From my experiences with implementing schema support in web2ldap during 
the last weeks I'd say it won't work in general.

And if you really wanna mandate the client having to look at the schema 
for implementing the matching rule 2.5.13.0 you're happily mixing 
semantics and syntax and the whole model is seriously flawed.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 01 Sep 2002 09:54:34 -0700

>Same issue in draft-ietf-ldapbis-models-02:

Most certainly.  The issue is LDAP wide.  My comment was
to note that [ldapbis-models] now defines the <oid>
production and states the base implementations requirements
associated with it.

I believe that LDAP use of short names as aliases for
OIDs is fundamentally flawed and is the root cause of
multiple interoperability and security problems.  You've
also noted that reliance on subschema discovery is also
quite problematic, I agree.  Aside from being difficult
to implement, there are numerous cases where subschema
discovery cannot be used to disambiguate short names.
For example, subschema is useless for disambiguating
short names in DNs.

In regards to your specific suggestion to resolve the
problems, I note that one might as well eliminate <descr>
choice than prefer <numericoid> over <descr>...

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Sun, 01 Sep 2002 18:59:22 +0200

Kurt D. Zeilenga wrote:
> multiple interoperability and security problems.

+1

> choice than prefer <numericoid> over <descr>...

+1

(at least to make an implementation of 'objectIdentifierMatch' 
(2.5.13.0) even possible.)

Ciao, Michael.