[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 (1.1.2.1):
>
>> 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:
ldap://ref.example.com/cn=sub,cn=ref,dc=example,dc=com
or
ldap://ref.example.com/
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]