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

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

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/21/04 2:14:38 PM >>>
>A few more reasons to use an extended operation here:
>
>MessageId handling - if we assume messages from multiple
>  clients are multiplex over one session to the chained
>  server, use of a control would require messageId munging.

I purposely defined the 'wrapped' thing to be specific operations and
controls (not LDAPMessage) so that we wouldn't have two different
messageIDs. I can change it back, but I note for the scenario above
would require the sending DSA to also provide the incomming user's
identity using something like the proxy AuthN control, or by adding
another 'originator' field to the chained request.

>Special bind behavior - a chained bind shouldn't change
>  the LDAP association of the chaining session.   If
>  a chaining control were used, that control would have
>  to alter bind semantics.

Yes, a further example of the first reason.

>Operation-level signatures - use of a chaining
>  extended operation could be compatible operation-level
>  signature extensions (e.g., RFC 2649), whereas use of a
>  chaining control would likely not be compatible (or
>  would likely require special handling to be compatible).

Yes.

Jim

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