Re: draft-ietf-ldapbis-protocol - controls

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Jim,

Under the current [Protocol] wording, the server which
recognizes a control properly attached to a request is
obligated to make use of that control in performance of
the operation.  As this establishes a client expectation,
that server is not freed from this obligation to the
client simply because it chooses to chain the whole
operation to another server.  And that's a major problem.
[Protocol] has established the wrong client expectation.

The client expectation of a request+control where the
control is non-critical is for the directory service
(whether involving one or many servers) will provide
service by either performing the operation indicated
by the request+control or the operation indicated by
the request, and hence, that all discernable outcomes
of the operation performed including all intermediate
and final results, all DIT changes, etc.) will be
entirely consistent with the choice the service makes.

As long as the service has yet to produce an outcome
that has a discernable difference between the choices,
the service maintains the choice.  Once it has produced
an outcome which has discernable difference, the
service is locked into its choice.  But we don't
need to confuse folks with "begin execution" stuff.

We simply need to say something like:
   If the server recognizes the control type and it is
   appropriate (in the server's determination) for the
   operation, the server will perform the requested
   operation as extended by control.  Otherwise, ...

Kurt


At 08:11 AM 4/1/2005, Jim Sermersheim wrote:
><snip>
>>I am not suggesting that servers do any back-tracking to mitigate the 
>>failures encountered while processing a request accompanied by 
>>non-critical controls. Only stating that the presence of a non-critical 
>>control should not cause a server to choose not to *begin* executing the 
>>accompanying request. Once the server has decided to begin executing the 
>>request, any incidental errors should of course be reported back to the 
>>client as usual.
>
>Servers deciding what it means to "begin execution" is what will cause confusion and different implementations to behave contrary to clients expectations.
> 
>Some servers might, during the process of name resolution, discover that the non-critical control is not allowed or supported in that part of the tree, and drop it. If this is a "dereferenceAliases" control, then dropping it at this point may constitute partial service of the control. If it's a different control, it may be safe to ignore the control after, or during, name resolution.
> 
>Some servers might evaluate a search request, apply the filter to the backing database, and not until the first object candidate is located peer into the ber packet holding the attribute selection list. At this point the server may decide that a non-critical control is at odds with something in the selection list. Now, this server may safely ignore the control, but ignoring the control might (or might not) require the server to re-apply the original filter to the backing database, so instead, it might just choose to fail the operation.
> 
>Re-reading your original post, I think slapd is being overly strict anyway. The control was in fact not recognized by the ultimate service it was sent to and thus should have been dropped (if not also being used in other contexts). This is the same as a non-critical control attached to a request which immediately chains to another server (with no part of the operation being affected prior to the chaining). In other words, if the server can determine that the non-critical control is not recognized or appropriate for the operation, then it can ignore it (as long as it can ensure it will not be applied partially). Changing the definition of appropriate *might* alleviate part of your original concern, and it might not. If a non-critical manageDSAit is attached, it can be ignored if it is known that it will only be applied to a single context/backend. But if the request can span backends, or will be chained, then the original problem is still there.
> 
>