On Wed, Feb 15, 2012 at 3:26 PM, Emmanuel Lécharny <email@example.com>
let's suppose we have an entry like :
dn: cn=john doe, ou=system
cn: john doe
sn: john doe
Let's now suppose that we want to camel-case the cn to have an entry like :
dn: cn=John Doe, ou=system
cn: John Doe
sn: john doe
Currently ADS does not support such a modification : it considers that it's a modifcation of an entry on itself, and it's not allowed. (cn is case insensitive, so basically, it's really a modification on itself).
You saying this is two ops (modify + modifyDn) that is not allowable in one shot?
Now, from the user PoV, this is a bit painful, because even if cn is case insensitive, the user wants to see the DN as he provided it (after the rename, he may expect dn: cn=John Doe, ou=system).
Q1 : should we allow such a rename ? (it will modify the RDN *and* the attribute)
So OK I see now, you just did a moddn on the entry changing the DN to use an camel humped cn value as the last name component when it was all lower case.
Let's take the basis case to understand this a little better. Suppose we did the moddn and it was a totally different CN such as 'foo bar' in your example. In this case what does the protocol state? I think in this case the cn: foo bar attribute value pair is automatically added to the entry right?
Going back into our problem. If the difference in the new name is a case change on a case insensitive name component attributeType then we should preserve the case supplied by the user. In this case I would suggest replacing the cn=john doe with cn=John Doe.
Q2 : if we modify the cn only, should the RDN be modified too ? (currently, ADS does modify the CN, but not the RDN)