Re: referrals question

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

At 02:35 PM 8/26/2003, Jim Sermersheim wrote:
>All,
>
>Currently, [Protocol] (Section 4.1.10) says: "If an alias was
>dereferenced, the <dn> part of the URL MUST be present, with the new
>target object name". This assumes....

I think this is assuming that the URL is an LDAP URL.  If you
just s/the URL/a LDAP URL/ here, the sentence is fine.  Likewise
in following sentences.

I think we need only specify handling of LDAP URLs.  While the
protocol is capable of transferring other URLs, specification of
such should be left to other documents.  We likely should clarify
that as well.  That is, in 4.1.11 and 4.5.3),
   Other kinds of URLs may be returned (as specified in future
   documents) so long as the operation could be performed using
   that protocol.

Thoughts?

Kurt

>that there is a <dn> part in the
>referral URL. [Protocol] says that other kinds of URLs can be returned.
>There are no requirements that all types of URLs contain a place for a
>DN. So, if an alias is dereferenced while resolving a name, and the
>referral contains non-LDAP URLs, is the server expected to:
>
>a) not return those non-LDAP referrals?
>b) only return non-LDAP referrals where the server knows the format,
>the URL format allows a DN, and the server fills in the DN part
>c) return the non-LDAP referrals as they exist in the data store (if
>they exist at all), even if no knowledge of DN placement is known.
>
>I note that another case where the server should provide the dn part is
>where a reference object has been placed and the referral attribute has
>the dn part populated (and that dn is different from the dn of the
>reference object). If the name being resolved is subordinate to that
>reference object, the dn of the referral(s) should reflect the DN held
>in the referral attribute plus the unresolved portion of the original dn
>on the operation.