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

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 21 Jun 2004 16:40:08 -0600

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.

For #2, the I-D does this, but not in the way you are thinking.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 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
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 21 Jun 2004 16:23:34 -0700

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