Re: [jira] Commented: (DIREVE-173) On modifyRdn server now adds additional Rdn attribute

[Stefan Zoerner]

Hi Trustin!

Here is an example for the first case.

-----------

# create an entry for a person
#
dn: cn=Myra Ellen Amos,dc=example,dc=com
changetype: add
objectclass: top
objectclass: person
cn: Myra Ellen Amos
sn: Amos
description: an American singer-songwriter

# Change RDN
# old RDN value of cn should continue to be in place
#
dn: cn=Myra Ellen Amos,dc=example,dc=com
changetype: modrdn
newrdn: cn=Tori Amos
deleteoldrdn: 0

# Change RDN a second time
# old RDN value of cn should continue to be deleted
#
dn: cn=Tori Amos,dc=example,dc=com
changetype: modrdn
newrdn: cn=Myra E. Amos
deleteoldrdn: 1

-----------

I applied it to IBM Tivoli Directory Server 5.2 (just to be sure) and the result (after both modrdn) is:

dn: cn=Myra E. Amos,dc=example,dc=com
objectclass: top
objectclass: person
cn: Myra Ellen Amos
cn: Myra E. Amos
sn: Amos
description: an American singer-songwriter

I think it is logical. The first modrdn adds a value to cn and does not delete the old value of the cn.
Therefore, Tori has two values for attribute cn after the first modrdn, one of them forms the rdn "cn=Tori Amos", the other "cn=Myra Ellen Amos" does not (cn allows multiple values).

The second operation adds a new value for cn ("cn=Myra E. Amos"), uses it as the new rdn, and deletes the attribute value of the old rdn ("cn=Tori Amos").
As a consequence, the attribute value "cn=Tori Amos" is gone, but "cn=Myra Ellen Amos", which was not part of the rdn not.

The point here is that cn allows multiple values. Behavior is different otherwise.

I hope this helped -- Greetings from Hamburg,
    Stefan

Btw.: Just another example why a test suite for all basic protocol operations would be worthwhile. I work on a first version of  using JNDI. But I already faced some (minor) problems, because some LDAP operations are very difficult to simulate with JNDI (obviously not the idea of a protocol test suite, to use work arounds ...).