Re: [ldapext] Chained Operation (control, extended op, or op?)

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

Regarding intermediate response (like searchResultEntry) embedded in a
ChainedResponse Extended Response. I think the proper way to do this is
to use an IntermediateResponse message to embed these. So, for a chained
search, the searchResultEntry and searchResultReference messages woul
dbe returned in a ChainedResponse IntermediateResponse message, while
the searchResultDone would be returned in a ChainedResponse
ExtendedResponse message.

Jim

>>> Jim Sermersheim 6/23/04 11:37:46 PM >>>
I'm currently judging consensus in favor of using an extended operation
to pass the chained operation between DSAs. If you disagree, please
reply. Some other things to consider are:

Would it be better to create a new operation?

Is it strange to allow intermediate responses to be returned in a
chained response?

Let me know if you have any issues, otherwise, I'll try to move
forward.

Jim

>>> "Jim Sermersheim" <jimse@novell.com> 6/21/04 11:51:31 AM >>>
All,

I'm attaching a not-ready-for-prime-time I-D which describes an LDAP
chained operation. Following X.518, I described it as an operation
(well, an extended operation) which contains the original message and
some chaining arguments. Some of my peers here have repeatedly argued
that there is no reason to define it as an extended operation, and
that
a control makes more sense.

What do others think? I can go either way.

If it's a control, I'd want to reconsider the targetObject and
entryOnly fields. If the control holds these, and is sent as
non-critical, and the receiving server doesn't support the control,
the
outcome will be erroneous. 

As an extended operation, we have two sets of resultCode, matchedDN,
errorMessage, and referral. This can be resolved by chosing yet
another
solution: Create a whole new operation (don't use an extended
operation). The new operation would not include the elements of
LDAPResult (well, the resultCode might be nice, but referral and
matchedDN is confusing).

I'll publish once I get some feedback on this, and fix up some
editorial issues.

Jim


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