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

Re: draft-ietf-ldapbis-protocol - controls

While I agree that the idea of testing the capabilities of the servers is not practical, I do think the idea of defining procedures for distributed operations which force controls to be critical and then process the results of distributed requests to form an appropriate response to the clients original request is potentially viable. This assumes that a control specification is not permitted to mandate that a control MUST be non-critical.

That said, I do agree that non-critical controls should be ignored rather then result in an error code for the operation. And this would simplify procedures for distributed operations for LDAP.

- Mark.

Howard Chu wrote: 
Jim Sermersheim wrote:

Sorry, if the operation is chained before being applied locally, don't change criticality.
And yes, other options are to test the capabilities of the other agents/backends, and to perform the behavior locally when not supported (a server or frontend could do this with the sorting or vlv control, but would have to gather all entries first.


The idea of testing the capabilities of the other servers/backends in advance really doesn't scale well. If you have a large distributed set of directory servers, where any server may be the frontend for yet another arbitrarily large set of servers, you may spend more time querying the capabilities (and getting unreliable answers) than actually processing the client's original request. Nor is this sort of thing properly cachable, since different servers with different capabilities may enter and leave the network at arbitrary times.

Following this line of attack is futile. It imposes additional overhead on the servers to collect a type of information in which the client has absolutely no interest.

There is nothing in RFC2251 that suggests the current LDAPbis interpretation is either intended or correct. Call me crazy, but I'd say a behavior that is fundamentally useless doesn't belong in the spec.

 >>> Mark Ennis <mark.ennis@eb2bcom.com> 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
 > 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 <mailto: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 <mailto: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