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

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

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:mark.ennis@adacel.com]
Sent: Wednesday, 23 June 2004 16:29
To: Jim Sermersheim
Cc: Ramsay, Ron; ldapext@ietf.org
Subject: Re: [ldapext] Chained Operation (control, extended op, or op?)


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:

> 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" <Ron.Ramsay@ca.com> 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:jimse@novell.com] 
> Sent: Wednesday, 23 June 2004 12:52
> To: Ramsay, Ron
> Cc: mark.ennis@adacel.com; ldapext@ietf.org 
> Subject: RE: [ldapext] Chained Operation (control, extended op, or
> op?)
> 
> 
> 
>>>>"Ramsay, Ron" <Ron.Ramsay@ca.com> 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
> 
> 
>>Ron
> 
> 
> -----Original Message-----
> From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On 
> Behalf Of Jim Sermersheim
> Sent: Wednesday, 23 June 2004 04:04
> To: Ramsay, Ron
> Cc: ldapext@ietf.org; mark.ennis@adacel.com 
> Subject: RE: [ldapext] Chained Operation (control, extended op, or
> op?)
> 
> 
> 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" <Ron.Ramsay@ca.com> 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-----
> From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On 
> Behalf Of Jim Sermersheim
> Sent: Tuesday, 22 June 2004 11:18
> To: mark.ennis@adacel.com 
> Cc: ldapext@ietf.org 
> 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. 
> 
> 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 <mark.ennis@adacel.com> 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
>>
>>
>>
> 
> 
> 
> _______________________________________________
> 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