It's a problem in developer release, the stable release is OK. That is 
why I didnt open any bug here.
Do not handle it, the behaviour is OK, I was wrong, it's LDAP feature 
to ignore spaces when manipulating the entry. The same for case 
sensitivity. ALICE BOB => error adding contact, exists.



I think this bug can be closed.

First of all, if composite attributes aren't working for you, please 
open a new ticket with a full description. I can't quite follow what 
you're talking about, and they are definitely not related to this bug.



Second, if I try to change a CN on my LDAP server to contain multiple 
spaces, I get an error. I can't save it to the backend (nothing is 
stripped) because the LDAP server thinks they're the same (old DN is 
cn=Alice Bob, new DN is quoted by Horde as cn="Alice  Bob" because of 
the multiple spaces).



So how _should_ we handle this?

Yes.Typical CN is contatenation of firstname and lastname, but can be 
anything. If you have two people with the same first/lastname in your 
database, the CN ist the right place to make this entries unique.
Yes, but the rest of DN after the first CN=... is constant. So I am 
always speaking about 'relative primary key'. For example the entry 
for 'Doe, John' in my LDAP has distinguished name (that's the case 
with comma in CN attribute which I tested now):



  cn=Doe\2C John,cn=robert,cn=private-addressbook,dc=mydomain,dc=com



but the part of DN   
'cn=robert,cn=private-addressbook,dc=mydomain,dc=com' is same for all 
my private addressbook entries.
No. Sorry, I am not PHP programmer and I do not understand horde 
framework. Anyway I am sure it is not LDAP issue. I think it was 
something changed in the handling of name, lastname and firstname 
attributes in the last time. About one year ago there was possible to 
define 'name' as array of first/lastname and put it into CN (see bug 
#2529). It was very good enhancement, because 99% of 
CN=lastname+firstname. Another reason for this enhancement is SyncML. 
Because there is nothing like CN in mobile/pda contacts, this 
attribute is always mapped as 'lastname<space>firstname' (should be 
configurable?). Here is snippet of my old map:



  'name' => array('fields' => array('lastname', 'firstname'),

                               'format' => '%s %s',

                               'attribute'=>'cn' ),



This does not work in the current CVS revision.  So I would start to 
search here.

Not sure what you mean - if the name is edited, then CN has to change 
since that's the name element. And really the DN should be the primary 
key, not CN, right?



Anyway, do you know where the space is diappearing?

Yes and no.

1.  Comma in common name seems to work now for me

2.  Multiple spaces are still replaced with one space.



     cn=John<space><space>Doe



     is saved into backend as



     cn=John<space>Doe



IMO cn is like a primary key here. Why do we manipulate it before 
saving in the  backend?

I believe this has since been fixed - can anyone verify that it is or isn't?

Turba's common name is in LDAP addressbook maped to the attribute cn. 
This attribute is in LDAP schema inetOrgPerson classified as required, 
rdn, i.e something like 'relative primary key'.  In sources.php the 
following mapping between turba and ldap attributes is defined (snippet)



        '__key' => 'dn',

         'name' => 'cn',

         'firstname' => 'givenName',

         'lastname' => 'sn'



When cn contains comma, example common name = 'Doe, John' (that is 
done when SyncML inserts  new entry),  LDAP server converts this 
common name into the string 'cn=Doe\2C John'.  When later any other 
attribute of this record is modified, save complains about duplicate 
record - error 68: Already exists (see the attached ldap.log). IMO 
Horde compares the string 'Doe\2C John' with 'Doe, John'. Because they 
differs, Horde evaluates this as primary key change and tries to 
modify this key. The similar situation happens when common name 
contains more then one space between words. This multiple spaces are 
striped out by LDAP server before dn is saved.