Re: draft-ietf-ldapbis-protocol - controls

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

At 11:09 PM 3/31/2005, Mark Ennis wrote:
>Kurt D. Zeilenga wrote:
>>At 10:14 PM 3/31/2005, Mark Ennis wrote:
>>
>>>Kurt D. Zeilenga wrote:
>>>
>>>>At 08:49 PM 3/31/2005, Jim Sermersheim wrote:
>>>>
>>>>>I believe the broad interpretation of "appropriate" leads to
>>>>>far more interoperability problems than the narrow view. I'm
>>>>>glad to see that you don't believe a control can be partially applied.
>>>>This, I think, needs to be made crystal clear.
>>>A control which results in modification of multiple objects must
>>>not be partially applied, but what about a control that modifies
>>>the behaviour of a query?
>>
>>Meaning that given a request+control where the control is
>>non-critical, the server is to perform either the operation indicated
>>by the request OR to perform the operation indicated by
>>request+control.
>>The server cannot perform a portion of the operation as indicated by
>>request+control and a portion of the operation as indicated by
>>request.  For instance, it would be inappropriate for a server, in
>>response to a search+manageDsaIt request, to only apply the semantics
>>indicated by the manageDsaIt to a subset of the results.  The server
>>is obligated to apply those semantics across all results or no
>>results.
>But this does not address a distributed environment where a server chaining a request may not know the capabilities of the servers it may chain a request to.

Some operations cannot be chained, or easily chained.  That's
a issue with their specification.  That is, if the semantics
of that operation (whether defined solely by a request, or
defined by a request plus some number of controls) allow
different actions to be applied to entries of interest,
then that's that.  If the specification of that operation
requires that the same actions be all entries, then that's
that.

The server cannot do the former when specification prescribes
the latter.

But where the client has requested that either operation
X or Y be performed, the server has a choice of doing either
X or Y.  But it cannot do Z.

>A search request or a tree delete request may be chained to multiple servers, each with different capabilities. The only way to enforce the requirements you have stated is to never apply the control.

Depends on the semantics of the operation (defined by the
request+control, as specified in the control specification).

The protocol specification is not defining the semantics of
operations defined by request+control.  The protocol specification
is defining what operations may choose between to perform.  A
client sending a request with a non-critical control is
requesting one of the following be performed:
        a) operation defined by request+control
        b) operation defined by request (less control)

Howard and I argue that the server choose b) if it unable
or unwilling to do a).  The server does not have the option
(c) to perform operation a) on a fraction of the entries of
interest and operation b) on the another fraction of the
entries of interest.

Note that if a) allowed different actions to be applied to
different fractions of entries of interest, while the server
would have the option to do so, that's part of a).  That
is, options with a) shouldn't be regarded as a new operation
(c), but as options within the operation (a).

>>>A control requesting extra information from each entry in a search
>>>result, for example a control to reproduce the behaviour of the
>>>modifyRightsRequest in a DAP read operation, may be partially
>>>applied, without having any serious implications.
>>
>>Different kind of "apply".  If the prescribed semantics of the operation indicated by request+control allow for some of these modifications to be applied to the DIT and others not, that fine. But
>>if the prescribed semantics of this operation required that all or
>>none of these modifications to be applied to the DIT, then that's
>>what has to be done in performance of that operation.
>The example I quote is a request for information about what parts of entries are modifiable, not a request to modify anything.

Matters not to my argument.  See below.

>Again, in a distributed environment, servers supporting the control may return a control response indicating the information as requested. Servers not supporting the control may ignore the control.

Depends on the specification of the operation indicated by
the request+control.  If the specification says MUST
provide the requested information for each entry returned,
then the server violates the protocol if it returns an
entry without that information.

If on the other hand, the specification says the information
is OPTIONAL, then the server need not ever return the information.

>The application of the control in this case would be "partial" and quite safe.

If the control specification says the extra information MUST
be returned, it is not safe nor appropriate for the server to
ignore that MUST.

>>>To what extent should the allowance to partially apply a control be
>>>regulated by the specification controlling the infrastructure, i.e.
>>>[protocols], versus the control specification?
>>
>>The control specification defines what operation to perform in
>>response to a request+control message.
>>Where the control is non-critical, the server has a choice of perform
>>either: the operation indicated by the request as extended by the
>>control or the operation indicated by the request.
>>Performing some other operation is not an option.
>This assumes complete knowledge by the server of how the control will be applied over the entire area affected by the operation.

I am assuming that the server is providing requested service.
If that service requires knowledge to perform that the server
doesn't have, then the server shouldn't perform that operation.
If it has the choice of performing another operation (by ignoring
a non-critical control), it would be appropriate for it to
give that a go.  That operation might require knowledge the
server doesn't have either, in that case, if there or no
other operations to choose from (no more controls to ignore),
an error will have to be returned.

>In a distributed environment, this knowledge cannot be guaranteed, meaning the above requirements can only be met by never doing request+control in these circumstances.

In a distributed environments, knowledge for any operation, including
base operations, is not guaranteed.


>>>For example, a control specification for a tree delete control
>>>should include a discussion of considerations relating to
>>>application of the control in a distributed environment or across
>>>different contexts, regardless of what [protocols] may say.
>>