I believe better wording would be ... functions should normalize attribute names. Because currently the issue is they are case sensitive.

It's a twofold issue... Functions should normalize attribute names for their internal representation (see #50373), but they should respect the case provided by the user and returned by the server.

@vashirov I think even if you were to do ldapsearch ... '(uid=name)' CN, you would get back the attribute as "cn: name". So Ithink that just normalising and deduping on the function call is fine, because we should respect the case the server returns to us in the result.

@vashirov I think even if you were to do ldapsearch ... '(uid=name)' CN, you would get back the attribute as "cn: name".

This is true for openldap, but 389-ds returns attribute name as requested:

$ ldapsearch -x -b dc=example,dc=com -s base DeScRiPtIoN
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: DeScRiPtIoN 
#

# example.com
dn: dc=example,dc=com
DeScRiPtIoN: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

That is right it returns the first requested attribute name

ldapsearch  -xLLL -h localhost -p 38901  -b "dc=example,dc=com" "(gidNumber=99999)" 
dn: cn=demo_group,ou=groups,dc=example,dc=com
...
cn: demo_group
gidNumber: 99999

ldapsearch  -xLLL -h localhost -p 38901  -b "dc=example,dc=com" "(gidNumber=99999)" GidNumber GIDNUMBER gidNumber
dn: cn=demo_group,ou=groups,dc=example,dc=com
GidNumber: 99999

So then our normalise just has to dedup and remove the subsequent attribute names on request then?

I think that if 'Accounts' wants to mimic the 389-ds behavior, it could build a list of requested attribute as they are provided by the client application. An attribute is added in the list at the condition it is not already present (case insensitive). Then when returning the attribute name/value, 'Accounts' returns the name as present in the list.

Actually we'd do this in DSLdapObject because then every type would get the behaviour that we want here.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3474

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.