Purpose of unableToProceed (was: Re: [ldapext] Chained Operation (control, extended op, or op?))

["Jim Sermersheim" <jimse@novell.com>]

>>> "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).

Jim

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext