Re: [Fwd: Re: (ITS#5881) referral problem with refreshAndPersist mode]

["Brett @Google" <brett.maxfield@gmail.com>]

On Sat, Jan 24, 2009 at 3:19 PM, Howard Chu <hyc@symas.com> wrote:

Unfortunately, I think the spec is broken here. There's no way for the consumer to record the references it receives, because they're not accompanied by the DN of the entry that triggered the reference. It would have made more sense for the provider to send the references uninterpreted, as regular LDAP entries.

Any suggestions?

It would make sense for a syncrepl to send the referral without any modifications or de-referencing, IFF the entity querying is also syncrepl. Because syncrepl is only replicating state of a DIT (it is in itself not really interested in the data a referral might return) and is not and "end user", it should act as if it is "managing" referrals, and not-de-referencing them.

I'm assuming, the intent of a referral is to make a reference to some other data for a "end user", and usually because that data is of a somewhat transient state, or that it is a delegation to another server for which the local server is not authoritative. 

I think the referral should be copied without de-referencing by syncrepl, then when a "end user" asks for that same data from the replica (querying the replica to which the entry has been replicated by syncrepl), they will get data de-referenced at the time of thier query, rather than getting some stale re-referenced data that syncrepl may have copied some (perhaps a very long) time ago when the data was replicated and de-referenced by syncrepl.

So probably as a consequence syncrepl client should ask for referrals to not be de-referenced, or the server should not de-reference referrals by default IFF the query is part of a syncrepl session. This assumes the server can easily distinguish a syncrepl client from a "end user". But it means the replica would de-reference referrals closest to the end user, which seems to best preserve the intent of a referral IMHO.

Cheers
Brett