On Wed, Feb 15, 2012 at 3:26 PM, Emmanuel Lécharny <[email protected]>wrote:
> Hi guys, > > let's suppose we have an entry like : > > dn: cn=john doe, ou=system > objectclass: person > 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 > objectclass: person > 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). > > So > > 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) > > wdyt ? > > See above. -- Best Regards, -- Alex
