case sensitivity in DN component attribute

[Ben Poliakoff <benp@reed.edu>]

Running OpenLDAP 2.2.28...

I recently noticed some interesting, and initially confusing, case
related behavior related to attributes that are components of an LDAP
entry's DN.

In a local schema file an attribute was defined, let's call the
attribute 'ABFoo'.  LDAP entries are then created with DNs like this:

    ABFoo=bar,ou=sales,dc=example,dc=com
    ABFoo=baz,ou=sales,dc=example,dc=com

So far so good.  Then I decided to modify the local schema file,
modifying the case of the attribute name from 'ABFoo' to 'abFoo'.
Initially everything seemed fine, I was able to use ldapsearch to look
up the ABFoo/abFoo entries without any trouble.  LDAP searches worked
equally well when I searched for 'ABFoo=bar' or 'abFoo=bar'.

But when I tried to modify or delete one of these entries slapd gave me
an "error 32":

    "No such object"

Eventually I realized that the problem had something to do with the
changing of case of the attribute name.  I tried adding an additional
name for the 'abFoo' attribute (the older style 'ABFoo') in the local
schema file, but slapd complained that the name 'ABFoo' was a duplicate
of 'abFoo'.  So slapd clearly enforces some sort of case *insensitivity*
in parsing schema files.

Once I reverted the schema file to the original 'ABFoo' version I was
able to delete and modify the entries in question.  But of course the
newer LDAP entries with DNs like:

    abFoo=busted,ou=sales,dc=example,dc=com

...were no longer modifiable.

Assuming I've described the symptoms clearly enough (and I likely
haven't), is this behavior a "bug" or is it just a demonstration of the
kind of trouble that can occur with "casual" schema file modification?

Ben