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