There was some confusion about this in RFC 1777 and 1778. It's
been cleared up in later drafts, both for LDAPv2 and LDAPv3.
We standardized on the shorter names, and listed the supported
attributes explicitly. Take a look at these:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv2-protocol-01.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv2-attributes-01.txt
This also makes things consistent between LDAP and 1779, as far
as the type names used.
> Can a client that uses commonname instead of cn rightly claim to be an
> LDAP client since it appears to be at least in violation of 1779?
It's certainly wrong to use commonName in a DN, since that violates
1779, it's arguable for LDAP as described in 1777 and 1778, which
is why we clarified it.
> Alternatively is there anything I can set up in the configuration file
> that maps cn to commonname and vise versa?
There was an aliasing feature in the ldap-3.3 code, but when I sat
down and looked at the code turns out it was just never going to
work. What was I thinking, I'm sure I don't know.
Anyway, that's not something I'll likely be able to fix in the
umich release, but it will be fixed (is fixed, even as we speak!)
in the Netscape Directory Server. (shameless plug ;0) -- Tim