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

[Mark Ennis <mark.ennis@adacel.com>]

Jim,

It is my opinion that you need to define your procedures for distributed 
operations and define your chaining argument and chaining result based 
on those procedures. If you choose to assume that the procedures for 
distributed operations are those defined in X.518, then you will need to 
include fields in the chaining arguments and results that are required 
by those procedures. In particular, the operation progress information 
is critical to the name resolution procedures defined in X.518 and I do 
not see how you can use these procedures without this field in the 
chaining arguments and in the trace information (and in referrals).

Where information critical to X.518 procedures for distributed 
operations is not supported, new procedures need to be defined to 
accomodate chaining of LDAP operations.

- Mark.

Jim Sermersheim wrote:

> 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