[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

At 03:37 PM 6/21/2004, Jim Sermersheim wrote:
>>>> "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,

Please do.  IIRC, message signatures encompass the whole
LDAPMessage (less the signature control).

>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.

"Another" or "an"?  That is, do we need more than one
'originator' field?



BTW, I'd like to add support for chaining SASL bind exchanges.
This will require some fields beyond those offered by the
X.518 ChainingArguments/ChainingResults structures.

Kurt 


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