Jim
*---- Forwarded Message *----
<snip>
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.