[ldapext] ChainedOperation.targetObject (are nssr's required)?

["Jim Sermersheim" <jimse@novell.com>]

All,

As has been discussed recently, X.518 sets the
ChainedOperation.targetObject to the parent of the next naming context
when multi-chaining (post name resolution) a one-level or subtree search
subrequest. There are a number of reasons for doing this -- some of
which seem to address consistency checks and performance issues.  But
there is at least one reason that is required. When multi-chaining a
search subrequest due to an nssr DSE, one has no choice but to pass the
parent of the next naming context (since the next naming context's name
is unknown).

Given that there is this requirement for multi-chaining due to an nssr
DSE, I can see proceeding in one of these ways:

1) State that for subrequests (chained requests after name resolution
has completed), ChainedOperation.targetObject is set to the name of the
reference DSE that caused chaining to happen (this may be overridden by
a DN in the ref attribute). In the case of a subr DSE, it will be the
name of the next naming context. In the case of an nssr, it is the name
of the parent of the next naming context. 

2)To support the other (performance and consistency) benefits, and to
more seamlessly integrate with existing X.500 implementations, follow
the X.518 model in this regard.

I'm just trying to test the waters to see which path to give preference
to. If lots of people strongly prefer #2, I might as well not even
investigate #1 any further.

Thanks.

Jim

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext