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

[Michael Ströder <michael@stroeder.com>]

Kurt D. Zeilenga wrote:
> I note that these productions has been moved to
> draft-ietf-ldapbis-models, Section 1.3 (Common
> 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
> a section, 6.2, which briefly discusses
> "Short Names".  Please review.

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