directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Renaming an entry with a case insensitive RDN : how to handle it ?
Date Wed, 15 Feb 2012 22:54:54 GMT
Le 2/15/12 8:48 PM, Howard Chu a écrit :
> Alex Karasulu wrote:
>>     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.
> Agreed, that's the rationale in OpenLDAP.

I think there is a consensus on this. There is an opened JIRA, I'll fix it.
>> 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)
> The op is a Mod[R]DN, so absolutely, the most obvious thing that 
> *should* happen is to change the RDN. It's less obvious how to change 
> the cn attribute. E.g., if the delOldRDN flag was set, then I would 
> expect a complete change, but if not set, maybe the correct result is 
> to have both "cn=john doe" and "cn=John Doe" in the entry.
I don't see how possibly we can keep two values that are equals in the 
same attribute, considering that cn is case insensitive. Otherwise, how 
would you pull the right value when doing a search with "(cn=*oe)" ? Get 
twice the same entry ?

To me, I'd rather either replace the old cn whatever value the delOldRdn 
value could be. The real pb is the RDN itself : should we change it or 
not ? Considering that one can still use the ModRDN operation to change 
the RDN, I would rather keep the RDN as it was before.

All in all, it should not make a big difference for this case.

Thanks guys !

Emmanuel Lécharny

View raw message