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

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 21 Jun 2004 11:51:31 -0600

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 21 Jun 2004 13:00:19 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 21 Jun 2004 13:14:38 -0700

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.

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.

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

Kurt

---

From: Mark Ennis <[email-masked]>
Date: Tue, 22 Jun 2004 10:35:13 +1000

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.