Kurt said -
>"Hence, I don't grok:
> The controlError result code should be returned when an operation
> has succeeded but an attached control may have failed.
>
>It's my view that controls don't fail, operations fail. An
>operation with a control(s) extends the operation per semantics
>of the control(s)."
A better description would be - An operation may have failed due to a control, and the relevant information may be embedded in the control results.
An example would be a control like VLV failing due to a control specific field (offsetRangeError). There is currently not an error code that could be returned for the operation that adequately describes that the source of the error is in the control.
In retrospect, the need for the criticalControlError is probably not required and the controlError would be sufficient in both cases.
Michael
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, July 20, 2000 11:40 AM
To: Michael Armijo
Cc: ietf-ldapbis@OpenLDAP.org
Subject: LDAP Control Result Codes I-D
Michael,
Your I-D <draft-armijo-ldap-control-error-00.txt> discusses an
interesting problem.
I'm not quite sure I understand the need for two additional
codes. However, this may be due to my interpretation
of the control semantics and unavailableCriticalControl result
code.
It's my view that the critical of control does not impact the
processing of a recognized and supported control. That is,
if the server recognizes the control, supports the control
in the context of the operation, and is willing to process
the operation as extended by the control, then criticality
doesn't matter. The processing is done per the control and if
an error occurs in the processing of the control a suitable
error (as defined by the control) is returned. This may be
any result code other than unavailableCriticalExtension.
If, however, if the control is unrecognized, or unsupported in
context of the current operation, or the server otherwise is
unwilling to process the operation as extended by the control,
criticality matters. If critical, the unavailableCriticalExtension
result code is returned in the result (and this must be the only
response to the request). If not critical, the control is ignored.
A server must not partial process a control. That is, the
control applies to the whole operation or no part of the operation.
If the server initiates processing under the operation as
extended by the control(s) it must complete processing as
specified by these control(s). A server cannot in the middle of
processing the operation decide to ignore a control it has
chosen to honor (regardless of its criticality) (though it can
chose to abort the operation and return an appropriate non-success
result code).
Hence, I don't grok:
The controlError result code should be returned when an operation
has succeeded but an attached control may have failed.
It's my view that controls don't fail, operations fail. An
operation with a control(s) extends the operation per semantics
of the control(s).