[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: moddn (ITS#1192)
--------------CB9336B10E47697B1D6FFC52
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is a nice change, not allowing this operation if there are children present,
but to quote RFC 2251, Section 4.9 --
"4.9. Modify DN Operation
The Modify DN Operation allows a client to change the leftmost (least
significant) component of the name of an entry in the directory, or
to move a subtree of entries to a new location in the directory."
Are there any plans to properly implement the moddn function, according to the above
spec?
Rick
"Kurt D. Zeilenga" wrote:
> In looking at the code, it seems that there was no check. I
> added one (on the HEAD branch). Enjoy.
>
> Kurt
>
> At 01:53 PM 6/6/2001, Kurt@OpenLDAP.org wrote:
> >At 12:41 PM 6/6/2001, contact@outerrym.com wrote:
> >>Full_Name: Rick Brunelle
> >>Version: 2.0.7
> >>OS: linux (2.2.19-6.2.1smp)
> >>URL: ftp://ftp.openldap.org/incoming/
> >>Submission from: (NULL) (216.219.250.204)
> >
> >OpenLDAP 2.x is not properly detecting that the entry has
> >children. If it had, it would have returned unwillingToPerform
> >as the implement is unable to honor the request.
> >
> >
> >>When using Perl's Net::LDAP module, moddn does not seem to exhibit the correct
> >>behavior.
> >>For example, suppose that I have the following DN's:
> >>a=1,b=2,c=3,d=4
> >>b=2,c=3,d=4
> >>If I use moddn to change the superior of the second entry (b=2,c=3,d=4) so that
> >>its
> >>new superior is (c=4,d=4), the second entry's DN should now be b=2,c=4,d=4.
> >>According to spec, this should also move the first entry so that the first
> >>entry's
> >>DN should now be a=1,b=2,c=4,d=4. This is not what is happening. It only
> >>changes
> >>the DN of the entry modified by the moddn call without touching any children of
> >>the entry.
> >>. Isn't moddn supposed to be a recursive function?
--------------CB9336B10E47697B1D6FFC52
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
This is a nice change, not allowing this operation if there are children present, but to quote RFC 2251, Section 4.9 --
"4.9. Modify DN Operation
The Modify DN Operation allows a client to change the leftmost (least
significant) component of the name of an entry in the directory, or
to move a subtree of entries to a new location in the directory."
Are there any plans to properly implement the moddn function, according to the above spec?
Rick
"Kurt D. Zeilenga" wrote:
In looking at the code, it seems that there was no check. I
added one (on the HEAD branch). Enjoy.
Kurt
At 01:53 PM 6/6/2001, Kurt@OpenLDAP.org wrote:
>At 12:41 PM 6/6/2001, contact@outerrym.com wrote:
>>Full_Name: Rick Brunelle
>>Version: 2.0.7
>>OS: linux (2.2.19-6.2.1smp)
>>URL: ftp://ftp.openldap.org/incoming/
>>Submission from: (NULL) (216.219.250.204)
>
>OpenLDAP 2.x is not properly detecting that the entry has
>children. If it had, it would have returned unwillingToPerform
>as the implement is unable to honor the request.
>
>
>>When using Perl's Net::LDAP module, moddn does not seem to exhibit the correct
>>behavior.
>>For example, suppose that I have the following DN's:
>>a=1,b=2,c=3,d=4
>>b=2,c=3,d=4
>>If I use moddn to change the superior of the second entry (b=2,c=3,d=4) so that
>>its
>>new superior is (c=4,d=4), the second entry's DN should now be b=2,c=4,d=4.
>>According to spec, this should also move the first entry so that the first
>>entry's
>>DN should now be a=1,b=2,c=4,d=4. This is not what is happening. It only
>>changes
>>the DN of the entry modified by the moddn call without touching any children of
>>the entry.
>>. Isn't moddn supposed to be a recursive function?
--------------CB9336B10E47697B1D6FFC52--