[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: draft-ietf-ldapbis-protocol - controls

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
past.

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 referrals.

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 <mark.ennis@acm.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: 
http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html



"Jim Sermersheim" < jimse@novell.com > 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.

Jim