Re: root.openldap.org

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:41 PM 8/11/00 +0200, Michael Ströder wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> Actually you should view the service as assisting your default
>> LDAP server in providing DN -> LDAP URI resolution.
>
>I see.
>
>> I'm still looking forward to the day that I can create a referral
>> in any server just by adding a named referral object with a
>> ref attribute of ldap:/// and rely on the server to expand
>> this URI on the fly
>
>Do you think it would make sense if a smart LDAP client makes the
>SRV lookup and URI expansion instead of relying on the LDAP server
>nearby?

Well, in the context of search continuations, a client would be
hard pressed to expand ldap:/// to anything meaningful...

However, in general, I think clients should be configured using
URIs.  If the URI doesn't have a hostpart but does have a DN,
I see no reason why the client shouldn't use DNS SRV to expand
the URI.  If the URI has a hostpart but no DN, the client can
lookup namingContexts and prompt the user as needed (to deal
with multiples).  If the URI provides has no hostpart and no
DN, the client needs additional information to do anything
useful.

>The client has to chase the referral anyway so it can make
>the DNS lookup if reading a ref attribute.

Non-management clients don't (and shouldn't) read the ref attribute
directly.  The ref attribute is operational, usually only visiable
if ManageDsaIt control has been sent, and MAY be used by the server
to DERIVE a referral or search continuation.   That is, the
client should not attempt to guess what referral/search continuation
a server might return, it just deal with the actual referrals/search
continuations as they are returned.

Kurt