[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft-ietf-ldapbis-protocol - controls
I find this comment from Steve Kille interesting:
Some extensions can safely be ignored without loss of service.
Others will simply not work if they are not understood and
need to be rejected. The criticality mechanism allows this
to be communicated. This is particularly important in a
store and forward messaging environment, or where
directory requests are chained.
<http://www.openldap.org/lists/ietf-ldapext/199802/msg00088.html>
I think the key point I and Howard are making is that by not
ignoring a recognized and applicable (per the specification)
non-critical control one cannot service, one causes an
unnecessary and inappropriate loss of service.
The language in RFC 2251 was:
If the server recognizes the control type and it is appropriate for
the operation, the server will make use of the control when
performing the operation.
I think it natural for implementors interpret "appropriate
for the operation" in a broad manner, and I think it clear that
many client and server implementors have interpreted "appropriate
for the operation" in a broad manner. Narrow interpretations,
such as viewing the language as a mandatory requirement
for servers to "make use" of applicable controls they recognize
leads to idiotic behavior.
For instance, I could code an LDAP server to "recognize"
every known request control but not support any of them.
Under the narrow interpretation taken by the WG, my server would
be obligated to turn unwillingToPerform (or some other
appropriate result code). I do not believe this is what was
intended by designers of LDAP. But regardless of their intent,
the interpretation taken by the WG will lead to significant
interoperability problems and hinder development/deployment
of distributed directory services.
What I think needs to be clarified is the above text is that
the server is to perform the operation, the whole operation,
as extended by the control. It cannot perform only part of
the operation as extended by the control. This, of course,
has some implications on distributed systems, but I argue
that the server ability to ignore applicable non-critical
controls is key to making such systems work in face of
extensions... which is what I think Steve was hinting at
in is 1998 ASID/LDAPEXT post.
-- Kurt
At 07:01 PM 3/31/2005, 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
>
>--
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support