Re: LCUP: subordinate references

I tend to prefer something like the first approach (for add, and mod). I
guess a delete would just be a delete.

>>> "Kurt D. Zeilenga" <[email protected]> 09/04/02 08:59PM >>>

The document is quite unclear how references are to be
handled.  What happens when a named subordinate referral
object [RFC 3296] within scope of the search is added,
deleted, or modified?  One approach is would be to
return a searchResultReference with a control much
like the EntryUpdateControl, but with the UUID of
the referral object.

Or one could just redefine (and rename) the
EntryUpdateControl to include the UUID.  (As I noted
previously, that would avoid the problems created by
clients not requesting entryUUID or servers not
returning it.)

Another approach would be require the presence of
the ManageDsaIT control in the request.  This, basically,
requests that all referral objects be treated as
entry objects.  However, the problem with this, is that
the ManageDsaIT control may be used to manage other kinds
of knowledge information.  It selects a management plane
within the DsaIT.  An LCUP with ManageDsaIT should be
treated as a LCUP request within the management plane
normally selected by the ManageDsaIt.  So, I think this
is not an appropriate solution.

Another option is to just to say the all referral objects
are treated as entry objects when the LCUP control is
present.

There may be other options.

I'm not sure what the best option is....

Kurt