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