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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:40 PM 6/21/2004, Jim Sermersheim wrote:
>For #1, I saw having two referrals as being confusing. When would the
>chained operation's referral field ever be populated? It seems that the
>embedded operation's referral would always be used.

When the chained server wishes to refer the chaining server to
another server to progress the chained operation (instead of
wishing to refer the originator to another server). 

>For #2, the I-D does this, but not in the way you are thinking.
>
>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/21/04 2:00:19 PM >>>
>I believe it best to design the chaining operation as an extended
>operation which "wraps" the chained operation (as well as provides
>additional "chaining" information), for three reasons:
>  1) separates chaining v. chained result information (e.g.,
>resultCode,
>        referrals, etc.),
>  2) separates chaining v. chained extension information (e.g.,
>controls),
>  3) may facilitate mapping to X.518 operations
>
>At 10:51 AM 6/21/2004, 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
>>
>>Content-Type: text/plain;
>name="draft-sermersheim-ldap-chained-op-00.txt"
>>Content-Disposition: attachment;
>>        filename="draft-sermersheim-ldap-chained-op-00.txt"
>>X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id
>NAA11981
>>
>>_______________________________________________
>>Ldapext mailing list
>>Ldapext@ietf.org 
>>https://www1.ietf.org/mailman/listinfo/ldapext 
>
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


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