[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: dn rewriting (was: do_modify & referral)

At 05:19 PM 2/14/01 +0100, Pierangelo Masarati wrote:
>"Kurt D. Zeilenga" wrote:
>> The current implementation requires that listed LDAP URLs be directly
>> subordinate as there is no LDAP URL DN rewriting code (yet).
>> For a detailed explanation of how DN rewriting *should* work (IMO), see
>>   draft-zeilenga-ldap-namedref-xx.txt
>>From the copy of 'draft-zeilenga-ldap-namedref-xx.txt'
>in the head branch of the cvs tree (
>> This draft expires 4 Jan. 2001.
>what's the current status?

I need to commit revision 2 (available from www.ietf.org).

>Moreover, it seems to me that
>there's very little 'rewriting' in there; it sounds more about
>referral selection policy. I thought some true dn rewriting
>capability was being discussed. Can you tell me anything
>about it, or give me some pointers, at least?

Assume you have:

        dn: cn=ref,dc=example,dc=com
        cn: ref
        ref: ldap://ref.example.com/cn=ref,dc=example,dc=com
        objectClass: referral

and you issue some request for cn=sub,cn=ref,dc=example,dc=com.
The referral returned can be:

as the latter is required to be treated by the client in the
same manner.  The current code trims the DN to avoid having
to rewrite it.   However, if you have:

        dn: cn=ref,dc=example,dc=com
        cn: ref
        ref: ldap://ref.example.com/cn=fubar,dc=example,dc=com
        objectClass: referral

Then trimming the DN doesn't work, you have to rewrite URL before
returning it.

Note the rev 2 allows:
        dn: cn=ref,dc=example,dc=com
        cn: ref
        ref: ldap://ref.example.com/
        objectClass: referral

which is to be treated the same as if the URL's DN was the DN
of the referral object.  Hence, more rewriting [namely for
search continuations]