"Ennis, Mark" <mark.ennis@adacel.com> 6/22/04 7:24:08 PM >>>
<snip>
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.
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.
So if a DSA holds inconsistent data which causes unableToProceed, but
there is always other continuation reference information avaliable to
progress the operation, will the inconsistency will go unnoticed? I
failed to realize that this was a 'soft' error like busy, and
unavailable are (also points I haven't yet mentioned in the I-D).