>>>> "dsg(a)mitre.org" == David S Goldberg
<dsg(a)mitre.org> writes:
[...]
ldap-search-entries returns nil for various attributes that have
legitimate values. This is breaking EUDC (about which I have another,
separate bug report and suggested patch). ldap-search-basic is
properly returning those values. Here's some sample tries from my
*scratch* buffer (I've selected the problem attributes for brevity;
most, if not all, other attributes are properly found).
(setq dsgldap (ldap-open "ldap-user.mitre.org"))
#<ldap "ldap-user.mitre.org" 0xbec5e0>
(ldap-search-basic dsgldap "(uid=dsg)"
"o=mitre.org" nil '("cn" "sn"))
((("cn" "Goldberg,David S.") ("sn" "Goldberg")))
(ldap-close dsgldap)
nil
(ldap-search-entries "(uid=dsg)"
"ldap-user.mitre.org" '("cn" "sn"))
((("cn" nil) ("sn" nil)))
ldap-host-parameters-alist
(("ldap-user.mitre.org" base "o=mitre.org")
("localhost:389" base "o=mitre.org"))
So I took a look around through ldap.el and found the
ldap-ignore-attribute-codings variable. On a whim I tried setting it
to t and lo and behold, ldap-search-entries properly returned the
values. I'm not sure what's broken here. Either ldap-search-entries
is inherently doing something wrong (what I suspect), or
ldap-ignore-attribute-codings should be set to t by default.
LDAPv3 specifies that attributes should be encoded according to their type, in
particular attributes of type string should use UTF-8. In ldap.el,
`ldap-ignore-attribute-codings' controls wether coding is applied to the
attributes. If we consider that LDAP v3 is the standard and we should enforce
it then its current default is reasonable and it's up to the clients of old v2
servers to change it. On the other hand the current default combined with
`ldap-coding-system` being nil when it should be utf-8 makes no sense...
Historically I set those variables as they are because LDAPv3 was the standard
and UTF-8 support in XEmacs was unbearably slow. I haven't tested UTF-8
support in XEmacs for a very long time. maybe it's now time to rethink those
defaults.
Additionaly things are supposed to work well nevertheless because
(decode-coding-string str nil) returns str. For some reason it seems to return
nil in your configuration.
Oscar Figueiredo