>>> Mark Ennis <firstname.lastname@example.org> 3/30/05 12:13:20 AM >>>
Jim Sermersheim wrote:
> I believe this is what our chaining server does as well, though we
> have talked about changing chained controls to be critical in the
> I think your work around could be implemented and render (somewhat)
> expected effects:
> Say a search operation has attached to it a non-critical control
> (which the DSA supports). When the local DSA chains, it forces it to
> be critical.
> If the operation was chained before the control was used in
> processing the operation, then any resultCode returned from the
> chained-to DSA would be preserved.
Such as an unavailableCriticalExtension resultCode when the original
request had no critical controls?
> If the operation was chained during operation evaluation after being
> partially supported by the local DSA, and if the chained-to DSA
> returned unavailableCriticalExtension, the operation could return a
> different error (which would indicate that the operation could not be
> completed as specified).
Might work, although this strategy would lead to a difference in the
results obtained depending on whether the server handles the chaining
versus returning referrals and the client handling followup of the
Possibly the question of "what result would a client get if it handled
requests to each individual context?" is worth exploring. I would be
inclined to think a client would send the same request to each context
with the control marked non-critical (or not bother to send it to the
contexts which do not advertise support for the control). This leads me
to be inclined to have a server replicate this behaviour rather than
return errors for non-critical controls.
>>>> Mark Ennis <_ email@example.com <mailto:firstname.lastname@example.org>_ >
3/29/05 6:11:00 PM >>>
> As indicated in the message Jim referenced, our server will ignore
> the criticality flag of a control it recognises. However, this does
> not entirely address the issue Howard raised.
> In a distributed environment, a server receiving a request may need
> to chain this request to a number of other servers, where the support
> of various controls in the different servers may be different. Where
> a given server receiving a chained request does not support a
> control, it will base its processing decision on the criticality of
> the control. So even if the server which received the request from
> the client can support a given control, the control will potentially
> be ignored for some part of the result set. This results in the
> effective behaviour of the server, which received the original
> request from the client, ignoring the non-critical control for some
> contexts, even though it does support the control. This is the way
> our server effectively behaves.
> The only way around this, at present, would seem to be to force all
> the controls in a chained request to be critical, which would seem to
> be counter to the client's request that the processing of a
> non-critical control is optional.
> Our policy is to handle controls, in general, in the way John
> McMeeking described, which is to ignore unsupported and inapropriate
> non-critical controls.
> - Mark.
> Jim Sermersheim wrote:
>>> From another vendor:
>>>>> "Jim Sermersheim" < email@example.com
<mailto:firstname.lastname@example.org>_ > 3/29/05 5:08:37 PM >>>
>> Our implementations do this:
>> Is the control recognized and appropriate (as specified) for the
>> operation? Yes, process the operation No, Is it marked critical?
>> Yes, fail with unavailable critical extension No, Ignore the
>> control and process the operation
>> This has been discussed at length in the past, and consensus was
>> that this was the original intent and that this is what should be
>> conveyed in the new document.
>> IIRC, there were interoperability side effects of allowing
>> "appropriate" to mean anything the server wishes it to mean.