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

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

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 21 Jun 2004 18:48:37 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 6/21/04 5:13:00 PM >>>
>At 03:37 PM 6/21/2004, Jim Sermersheim wrote:
>>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
>>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?

An. Currently there is no originator field in my proposal.

Jim

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

---

From: Mark Ennis <[email-masked]>
Date: Tue, 22 Jun 2004 14:48:20 +1000

Jim,

The operationProgress becomes important in name resolution when DSAs 
have subordinate/superior relationships. Traditionally LDAP servers are 
defined as "First-level DSAs" which means that the operationProgress 
information is of little value in processing of referrals.

It is not true that a receiving DSA will not get a nameResolutionPhase 
of "completed". This can occur when processing a search operation, where 
name resolution has completed, but the scope of the search includes a 
reference to a subordinate DSA. The search will be chained with the 
targetObject of the chainingArguments set to the name of the superior of 
the DSE containing the subordinate reference and the 
operationProgress.nameResolutionPhase set to completed (cf. X.518 
19.3.2.2.1 7a). This allows the subordinate DSA to confirm the 
targetObject is an immSupr DSE and proceed with the search from this 
point. If the subordinate DSA cannot resolve the targetObject as an 
immSupr DSE then it should generate ServiceError.unableToProceed to 
indicate an inconsistency in the hierarchical operational binding (i.e. 
the knowledge) between these DSAs.

X.518 assume that the first step for the processing of any operation is 
name resolution. The operationProgress is used to determine if the 
hierarchical operation binding (represented by the knowledge such as 
subordinate and superior references) is consistent. In the absence of 
the operationProgress, a subordinate DSA, on receiving a request for a 
naming context it does not recognise, will chain the request to a 
superior DSA. Where the hierarchical operational binding has become 
inconsistent between the superior and subordinate DSA, this could lead 
to a loop condition or an incorrect NameError.noSuchObject.

The operatonProgress in the traceInformation of the chaining arguments 
is used to support a situation where one DSA contains both superior and 
subordinate parts of the DIT to a second DSA. Because of aliases, the 
first DSA could have the same request chained to it at different points 
in the name resolution and needs to be able to distinguish between the 
incidents in order to allow the name resolution to complete.

N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the 
X.500 procedures for distributed operations. As far as I am aware there 
are no significant differences in more recent editions of this 
recommendation.

- Mark.

Jim Sermersheim wrote:

> Thanks Mark,
> 
> Yes, I do need to add better semantics and some implementation details.
> If people agree that this operation should be sent as an extended
> request, I'll do that and submit.
> 
> I couldn't find a reason why operationProgress was needed. For example,
> today's LDAP servers return referrals and search result references which
> LDAP clients can follow. Nothing is conveyed regarding the operation
> progress when those clients follow these referrals and search referral
> references. 
> 
> Furthermore, I don't understand what a receiving DSA does with this
> information. A receiving DSA will not get a nameResolutionPhase of
> completed, thus it's either notStarted or proceeding. Regardless of
> whether it's notStarted or proceeding, the targetObject contains the DN
> to be resolved (unless the value is the same as the base DN of the
> embedded operation). Will you let me know what I'm missing here?
> 
> Some of the other fields are left for future controls that I haven't
> had time to write up (specifically referenceType, timeLimit,
> excludeShadows, and nameResolveOnMaster). Each of these have utility
> outside of the chained operation, so I think defining them as controls
> in their own documents would be better.
> 
> Jim
> 
> 
>>>>Mark Ennis <[email-masked]> 6/21/04 6:35:13 PM >>>
> 
> 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.
> 
> 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
>>
>>
>>
> 
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 22 Jun 2004 17:07:36 +1000

Jim,

Operation progress is the only way of differentiating chaining from multichaining.

For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again!

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jim Sermersheim
Sent: Tuesday, 22 June 2004 11:18
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ldapext] Chained Operation (control, extended op, or op?)

Thanks Mark,

Jim

Jim,

- Mark.

and
argued
that
the
another

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 12:03:48 -0600

I assumed that the host *and* target object were considered when
performing loop detection. I haven't put this much detail in the draft
yet, but I assumed I had it covered. Here's what I should have said
about ChainedRequestValue.chainingArguments.traceInformation:
<<
This contains a set of URIs. Each value represents the address of a DSA
and DN that has already been contacted while trying to service the
operation.

The receiving DSA adds to this list, a URI (or URIs if it may be
contacted using multiple addresses or ports) value containing its
address and the target object of the operation. The target object is
constructed using the value of
ChainedRequestValue.chainingArguments.targetObject. If that value not
present, then the value of the base object in the
ChainedRequestValue.operationRequest is used.

If, after adding its own URI(s) to this list, there are any two URIs
that match <todo: describe how they are matched> a loopDetect (54) error
is returned. Otherwise, the modified list is used if the operation is to
be chained to a further DSA

Thus, in your example, the new target object is different from the
original target object when the operation is chained back to Server A,
thus no loop. Similarly, since the target object points to a local
naming context when the operation is chained back to Server A, it would
not want to chain to Server B.

There must be some scenario that I haven't thought about where the
targetObject and dsa are not enough to detect a loop (or that they would
cause a loop to be erroneously detected).

Jim

>>> "Ramsay, Ron" <[email-masked]> 6/22/04 1:07:36 AM >>>
Jim,

Operation progress is the only way of differentiating chaining from
multichaining.

For example, a request is sent to Server A, which *chains* it to Server
B. Name resolution is not complete. Server B performs it and, if it is a
search request, *multichains* is to subordinates A and C. Name
resolution is completed. Note that, with the name-resolution indicator,
Server A would normally return "loop detected" instead of performing the
request. Also note that, without the name-resolution indication, Server
A would want to chain the multichained request to Server B, again!

Ron

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

Thanks Mark,

Yes, I do need to add better semantics and some implementation
details.
If people agree that this operation should be sent as an extended
request, I'll do that and submit.

I couldn't find a reason why operationProgress was needed. For
example,
today's LDAP servers return referrals and search result references
which
LDAP clients can follow. Nothing is conveyed regarding the operation
progress when those clients follow these referrals and search referral
references. 

whether it's notStarted or proceeding, the targetObject contains the
DN

Jim

Jim,

is critical to the name resolution procedures defined in X.518 and I
do

- Mark.

and
argued
that
the
another

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 13:56:05 -0600

>>> Mark Ennis <[email-masked]> 6/21/04 10:48:20 PM >>>
>Jim,
>

I'm not sure I agree with this statement. Many LDAP servers are required to be populated with the context prefixes of the naming contexts they hold. Some allow a superior referral, but others don't. I think the distributed data model has never been fully defined for LDAP servers, so to date, the servers are a mish-mash of different elements of First Level DSAs and non First Level DSAs. 
Regardless of that, I am interested in finding out what scenarios require operationProgress.

>reference to a subordinate DSA. 

You're right * I wasn't thinking.

>The search will be chained with the 
>the DSE containing the subordinate reference 

This is not what LDAP returns as the DN part of a referral URI. So if we did it this way, the target object in a chained operation would be different from the 'target object' of a referral. If there's a way to keep the 'target object' consistent between these, I'd prefer it.

>and the 
>point. 
>If the subordinate DSA cannot resolve the targetObject as an 

My draft doesn't consider the need for checking the consistency of the distributed data model. If that is a requirement, I need to refactor it. I do have a couple questions relating to this.

1) Why must the immediatly superior name be passed as the targetObject? If the receiving DSA knows a chained operation is due to a subordinate reference (yes, that would require more information than the draft currently has), and the targetObject is set to the name of the DSE which caused the referral, then the receiving DSA can examine the parent of the targetObject if it wishes to perform a consistency check. Are there other reasons that the parent is sent as the targetObject?

2) LDAP Servers often store a DN in the URI which represents knowledge information (RFC 3296). This DN does not have to name the DSE that holds the knowledge information. This can be useful (though potentially dangerous) when mapping a local name to a different remote name (let's call this "name mapping"). For example, I may have a server that holds a subr DSE (well, a RFC 3296 referral) named id=Sharks,id=MyStuff where the ref attribute holds a value ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. I wouldn't clasify this as a good practice, but one that is allowed and used. If we pass the local name of a reference's parent as the target object (where that reference holds mapped names), it will surely cause any validation check to fail (in fact it will cause the operation to fail regardless of a validation check).

So I guess two questions for the list are:
a) Is it required that the chained operation facilitate distributed data consistency checks? If so, must it be done in the same manner as X.518?
b) Is it required that the chained operation allow for a distributed data model where disparate namespaces can be joined via "name mapping"?

>to a loop condition or an incorrect NameError.noSuchObject.

Right, for these scenarios I assumed that the return of either of these errors (loopDetected or noSuchObject) would suffice.

>incidents in order to allow the name resolution to complete.

If the targetObject sent to the first DSA is different each time the operation is chained to it, it should not detect a loop, and thus allow name resolution to progress.

>are no significant differences in more recent editions of this 

Thanks for the feedback. As you can tell, I have not implemented this, I have only used it as a guide in experimentally implementing enough of it in an LDAP server to come up to speed enough to start the I-D. I very much appreciate the help.

Jim

---

From: "Ennis, Mark" <[email-masked]>
Date: Wed, 23 Jun 2004 11:24:08 +1000

Jim,

My concern is not that you are not following X.518, but that you appear 
to be implying the X.518 procedures without providing the information 
required by those procedures. I think your draft needs to define the 
procedures for distributed operations for LDAP directories in order to 
ensure the information provided in the chaining arguments and results 
are sufficient to the procedures defined.

More response in-line below.

- Mark.

> This is not what LDAP returns as the DN part of a referral URI. So if we did it this way, the target object in a chained operation would be different from the 'target object' of a referral. If ther…

If I remember correctly, the argument for using the name of the superior 
of the subr DSE is so that multiple sibling subr DSEs, where the 
subordinate entries are in the same subordinate DSA, will result in a 
single continuation reference instead of one for each sibling, thereby 
reducing the number of chained operations required to complete the 
operation. It also makes the subr and nssr reference types generate 
equivalent continuation references. This may be another reason for the 
ChainingResults.alreadySearched field.

> 1) Why must the immediatly superior name be passed as the targetObject? If the receiving DSA knows a chained operation is due to a subordinate reference (yes, that would require more information th…

The targetObject is not set to the name of the superior of the subr DSE 
during name resolution. It is set to the target object of the operation, 
which may change from the originally supplied target object due to the 
dereferencing of aliases during name resolution. The 
operationProgress.nextRDNToBeResolved informs the subordinate DSA which 
RDN in the target object is the name of the context prefix to begin 
local name resolution on.
> 2) LDAP Servers often store a DN in the URI which represents knowledge information (RFC 3296). This DN does not have to name the DSE that holds the knowledge information. This can be useful (though…

The target object of the chainingArgument is not the superior of the 
subr DSE during name resolution. In the case of a named subordinate 
reference as defined in RFC 3296, it looks to me like a combination of 
an alias and a subordinate reference. I would re-write the target object 
by replacing the resolved portion with the name in the reference and 
then chain the request to the indicated server, if I was following X.518 
procedures for distributed operation.

> Right, for these scenarios I assumed that the return of either of these errors (loopDetected or noSuchObject) would suffice.

The main difference is that normally ServiceError.unableToProceed is 
used by the X.518 procedures to cause another continuation reference to 
be used if one is available, while the NameError.noSuchObject and 
ServiceError.loopDetected cause the operation to complete with an error. 
This is particularly relevant to processing of non-specific subordinate 
references, where the problem is not due inconsistency in the HOB, but 
is due to lack of knowledge in the superior about which naming contexts 
exist in which subordinate DSAs.

> If the targetObject sent to the first DSA is different each time the operation is chained to it, it should not detect a loop, and thus allow name resolution to progress.

I can think of an example where the X.518 procedures would permit the 
same request to be chained to a DSA more than once, each time with the 
same target object but a different nextRDNToBeResolved. The example may 
not be very likely but is potentially possible in a complex topology.

Suppose we have the following DSAs:

DSA1 has two context prefixes: c=au and ou=development,o=adacel,c=au.
DSA2 has one context prefix: o=adacel,c=au.
DSA3 has one context prefix: ou=view500,ou=development,o=adacel,c=au.

Appropriate hierarchical operational bindings have been established for:
DSA1 -> DSA2 -> DSA1 -> DSA3.

We are attempting name resolution on 
ou=testing,ou=view500,ou=development,o=adacel,c=au with from DSA1, but 
DSA3 in unavailable.

DSA1 attempts name resolution and ends up with two candidate references, 
one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an 
unavailable error so the operation is chained to DSA2. DSA2 attempts 
name resolution and chains the operations back to DSA1. DSA1 now has a 
second go at the name resolution on the request which fails due to DSA3 
being unavailable.

The first attempt DSA1 makes to resolve the target object it has an 
operation progress of { nameResolutionPhase proceeding, 
nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase 
proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the 
same. Without the operation progress information, the chained request 
from DSA2 to DSA1 would generate an incorrect loopDetected error.

The X.518 procedures allow a implementation the choice on how to proceed 
based on an attempt to chain receiving a busy, unavailable, 
unwillingToPerform or invalidReference error. They can try a different 
candidate continuation reference or return an error. This choice leads 
to the situation I have described.

I think situations with partial replicas could cause similar situations 
to occur.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 19:53:29 -0600

I agree, it needs to state which procedures are to be followed (X.518,
or yet-to-be document procedures in the I-D). I'm struggling with trying
to understand the subtleties of the X.518 procedures enough to judge
which direction is best.

The X.518 procedures are a pain to follow because rather than stating
the problems and then providing solutions, it just provides the solution
and occasionally hints at the problems being solved. I will spend some
time trying to put together a problem set, and then test whether the
procedures I had in mind will solve that set.

This message is getting long, so I'll reply to the remainder in
different messages.

Jim

>>> "Ennis, Mark" <[email-masked]> 6/22/04 7:24:08 PM >>>
Jim,

- Mark.

Jim Sermersheim wrote:
> This is not what LDAP returns as the DN part of a referral URI. So if
we did it this way, the target object in a chained operation would be
different from the 'target object' of a referral. If there's a way to
keep the 'target object' consistent between these, I'd prefer it.

If I remember correctly, the argument for using the name of the
superior 
of the subr DSE is so that multiple sibling subr DSEs, where the 
subordinate entries are in the same subordinate DSA, will result in a 
single continuation reference instead of one for each sibling, thereby

> My draft doesn't consider the need for checking the consistency of
the distributed data model. If that is a requirement, I need to refactor
it. I do have a couple questions relating to this.
> 
> 1) Why must the immediatly superior name be passed as the
targetObject? If the receiving DSA knows a chained operation is due to a
subordinate reference (yes, that would require more information than the
draft currently has), and the targetObject is set to the name of the DSE
which caused the referral, then the receiving DSA can examine the parent
of the targetObject if it wishes to perform a consistency check. Are
there other reasons that the parent is sent as the targetObject?

during name resolution. It is set to the target object of the
operation, 
which may change from the originally supplied target object due to the

> 
> 2) LDAP Servers often store a DN in the URI which represents
knowledge information (RFC 3296). This DN does not have to name the DSE
that holds the knowledge information. This can be useful (though
potentially dangerous) when mapping a local name to a different remote
name (let's call this "name mapping"). For example, I may have a server
that holds a subr DSE (well, a RFC 3296 referral) named
id=Sharks,id=MyStuff where the ref attribute holds a value
ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata.
I wouldn't clasify this as a good practice, but one that is allowed and
used. If we pass the local name of a reference's parent as the target
object (where that reference holds mapped names), it will surely cause
any validation check to fail (in fact it will cause the operation to
fail regardless of a validation check).

an alias and a subordinate reference. I would re-write the target
object 
by replacing the resolved portion with the name in the reference and 
then chain the request to the indicated server, if I was following
X.518 
procedures for distributed operation.

> a) Is it required that the chained operation facilitate distributed
data consistency checks? If so, must it be done in the same manner as
X.518?
> b) Is it required that the chained operation allow for a distributed
data model where disparate namespaces can be joined via "name mapping"?

> Right, for these scenarios I assumed that the return of either of
these errors (loopDetected or noSuchObject) would suffice.

be used if one is available, while the NameError.noSuchObject and 
ServiceError.loopDetected cause the operation to complete with an
error. 
This is particularly relevant to processing of non-specific subordinate

> If the targetObject sent to the first DSA is different each time the
operation is chained to it, it should not detect a loop, and thus allow
name resolution to progress.

Appropriate hierarchical operational bindings have been established
for:
DSA1 -> DSA2 -> DSA1 -> DSA3.

DSA3 in unavailable.

DSA1 attempts name resolution and ends up with two candidate
references, 
one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an 
unavailable error so the operation is chained to DSA2. DSA2 attempts 
name resolution and chains the operations back to DSA1. DSA1 now has a

being unavailable.

The X.518 procedures allow a implementation the choice on how to
proceed 
based on an attempt to chain receiving a busy, unavailable, 
unwillingToPerform or invalidReference error. They can try a different

to occur.

> Thanks for the feedback. As you can tell, I have not implemented
this, I have only used it as a guide in experimentally implementing
enough of it in an LDAP server to come up to speed enough to start the
I-D. I very much appreciate the help.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 23 Jun 2004 12:35:56 +1000

If the target object were the naming context of Server B, it would not be changed when multichaining back to A? Therefore, without looking at the state of name resolution, Server A would detect a loop.

(You can't set the targetObject to the naming context of the server you are sending the request *to* without changing the original request, because a one-level search may have to be performed as a base-object search. Mark has already said, I believe, that the target object in X.500 is set to the context prefix of the server *sending* the request.)

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jim Sermersheim
Sent: Wednesday, 23 June 2004 04:04
To: Ramsay, Ron
Cc: [email-masked]; [email-masked]
Subject: RE: [ldapext] Chained Operation (control, extended op, or op?)

Jim

Jim,

Ron

-----Original Message-----

Thanks Mark,

Jim

Jim,

- Mark.

and
argued
that
the
another

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 23 Jun 2004 12:43:26 +1000

I would think that the simplest method would be to only change the target object if an alias was dereferenced (or a name was *mapped*) and use operationProgress to prevent errors.

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Wednesday, 23 June 2004 05:56
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ldapext] Chained Operation (control, extended op, or op?)

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 20:52:21 -0600

>>> "Ramsay, Ron" <[email-masked]> 6/22/04 8:35:56 PM >>>
>If the target object were the naming context of Server B, it would not
be changed when multichaining back to A? Therefore, without looking at
the state of name resolution, Server A would detect a loop.

No, when Server B multichains the request to Server A, it sets the
ChainingArguments.targetObject to the subordinate naming context (or in
the case of the X.518 procedures, to the parent DN of that naming
context).

>(You can't set the targetObject to the naming context of the server
you are sending the request *to* without changing the original request,
because a one-level search may have to be performed as a base-object
search. Mark has already said, I believe, that the target object in
X.500 is set to the context prefix of the server *sending* the
request.)

Ok, then I'm confused. I thought in this case, X.518 says that the
ChainingArguments.targetObject is set to the parent of the subr DSE. So
unless that is a cp, it wouldn't be set to any cp. Furthermore, if the
original search has a scope of one-level, the X.518 procedures, by
passing the parent of the naming context in the
ChainingArguments.targetObject, automatically solve the problem since
the recieving DSA only has a single child under that targetObject.

Jim

-----Original Message-----
Subject: RE: [ldapext] Chained Operation (control, extended op, or
op?)

This contains a set of URIs. Each value represents the address of a
DSA

If, after adding its own URI(s) to this list, there are any two URIs
that match <todo: describe how they are matched> a loopDetect (54)
error
is returned. Otherwise, the modified list is used if the operation is
to
be chained to a further DSA

naming context when the operation is chained back to Server A, it
would

There must be some scenario that I haven't thought about where the
targetObject and dsa are not enough to detect a loop (or that they
would
cause a loop to be erroneously detected).

Jim

Jim,

For example, a request is sent to Server A, which *chains* it to
Server
B. Name resolution is not complete. Server B performs it and, if it is
a
search request, *multichains* is to subordinates A and C. Name
resolution is completed. Note that, with the name-resolution
indicator,
Server A would normally return "loop detected" instead of performing
the
request. Also note that, without the name-resolution indication,
Server
A would want to chain the multichained request to Server B, again!

Ron

-----Original Message-----

Thanks Mark,

Jim

Jim,

- Mark.

and
argued
that
the
another

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 22 Jun 2004 22:43:30 -0600

I'm currently judging consensus in favor of using an extended operation
to pass the chained operation between DSAs. If you disagree, please
reply. Some other things to consider are:

Would it be better to create a new operation?

Is it strange to allow intermediate responses to be returned in a
chained response?

Let me know if you have any issues, otherwise, I'll try to move
forward.

Jim

>>> "Jim Sermersheim" <[email-masked]> 6/21/04 11:51:31 AM >>>
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.

Jim

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 23 Jun 2004 15:05:30 +1000

After reading through X.518 I'm a little confused, too. Firstly, it seems to say that, when multichaining, targetObject should be set to the name of the reference, which is usually the context prefix of the target system. For a one-level search, entryOnly is also set.

However, Figure 23 seems to imply that targetObject is set to the immediate superior of the reference.

If you were to proceed on the basis of setting targetObject to the DN of the reference when multichaining, I think you are right that you don't need operationProgress. However, you will need entryOnly for one-level searches.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Wednesday, 23 June 2004 12:52
To: Ramsay, Ron
Cc: [email-masked]; [email-masked]
Subject: RE: [ldapext] Chained Operation (control, extended op, or op?)

Jim

-----Original Message-----

Jim

Jim,

Ron

-----Original Message-----

Thanks Mark,

Jim

Jim,

- Mark.

and
argued
that
the
another

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 23 Jun 2004 00:04:03 -0600

Yes, this was my initial (mis)understanding of entryOnly. It seems that
it's only needed when a one-level search encounters an alias that it
must dereference (after name resolution has completed). I still need to
read more. I get confused by the type of pseudo-code found in
19.3.2.2.1.7)b) where it says "if the value of the subset parameter is
oneLevel, set entryOnly to True". Are they talking about
ChainingArguments.entryOnly, ContinuationReference.entryOnly, or some
local entryOnly? I guess I'm discouraged by the notion that one needs to
reverse engineer pseudo-code to understand the subtleties of the
arguments being passed around.

Your last statement makes sense, other than it removes some of the
niceties explained by Mark in other messages (consistency checks and
indirectly, alternate referral candidates). I'll likely lose sleep
tonight.

Jim

>>> "Ramsay, Ron" <[email-masked]> 6/22/04 11:05:30 PM >>>
After reading through X.518 I'm a little confused, too. Firstly, it
seems to say that, when multichaining, targetObject should be set to the
name of the reference, which is usually the context prefix of the target
system. For a one-level search, entryOnly is also set.

However, Figure 23 seems to imply that targetObject is set to the
immediate superior of the reference.

If you were to proceed on the basis of setting targetObject to the DN
of the reference when multichaining, I think you are right that you
don't need operationProgress. However, you will need entryOnly for
one-level searches.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Wednesday, 23 June 2004 12:52
To: Ramsay, Ron
Cc: [email-masked]; [email-masked] 
Subject: RE: [ldapext] Chained Operation (control, extended op, or
op?)

No, when Server B multichains the request to Server A, it sets the
ChainingArguments.targetObject to the subordinate naming context (or
in
the case of the X.518 procedures, to the parent DN of that naming
context).

>(You can't set the targetObject to the naming context of the server
you are sending the request *to* without changing the original
request,
because a one-level search may have to be performed as a base-object
search. Mark has already said, I believe, that the target object in
X.500 is set to the context prefix of the server *sending* the
request.)

ChainingArguments.targetObject is set to the parent of the subr DSE.
So

Jim

-----Original Message-----

Jim

Jim,

Ron

-----Original Message-----

Thanks Mark,

Jim

Jim,

- Mark.

and
argued
that
the
another

---

From: "Ennis, Mark" <[email-masked]>
Date: Wed, 23 Jun 2004 16:28:39 +1000

Jim,

I agree with your interpretation of the ChainingArguments.entryOnly only 
being required for a oneLevel search when a subordinate of the target 
object is an alias. I think the use of entryOnly in sentences like the 
one you quoted are local parameters for the pseudo code. I also agree it 
is confusing.

- Mark.

Jim Sermersheim wrote:

>>If the target object were the naming context of Server B, it would
> 
> not

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 23 Jun 2004 17:00:59 +1000

I would think entryOnly is required even if an alias was not dereferenced. The target DSA will receive a one-level search from its root so it will perform it. But the sender may be wanting it to do a base-object search. The target DSA will not know which is required.

The pseudo-code maintains a list of continuation references, and this is where targetObject and entryOnly are placed. When the request is multichained to another DSA, these items are copied into the chaining arguments. If the request is not sent, the continuation reference can be added to the result.

Ron

-----Original Message-----
From: Ennis, Mark [mailto:[email-masked]]
Sent: Wednesday, 23 June 2004 16:29
To: Jim Sermersheim
Cc: Ramsay, Ron; [email-masked]
Subject: Re: [ldapext] Chained Operation (control, extended op, or op?)

Jim,

- Mark.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 23 Jun 2004 23:42:17 -0600

Regarding intermediate response (like searchResultEntry) embedded in a
ChainedResponse Extended Response. I think the proper way to do this is
to use an IntermediateResponse message to embed these. So, for a chained
search, the searchResultEntry and searchResultReference messages woul
dbe returned in a ChainedResponse IntermediateResponse message, while
the searchResultDone would be returned in a ChainedResponse
ExtendedResponse message.

Jim

>>> Jim Sermersheim 6/23/04 11:37:46 PM >>>

Jim

All,

Jim