[Date Prev][Date Next]
Re: Controls and criticality
On Nov 2, 2008, at 11:28 AM, Pierangelo Masarati wrote:
Kurt Zeilenga wrote:
On Nov 2, 2008, at 11:00 AM, Pierangelo Masarati wrote:
Kurt Zeilenga wrote:
Absolutely not. In making use of the control, critical or not, the
server can certainly return an error.
if the control is critical, the server cannot ignore it. It must
either make use of it as prescribed or fail.
if the control is non-critical, the server can choose to ignore
it. However, it should only do so before making use of it as
Some controls specifications are simply broken. No part of the
'making use of the control' should depend on the value of
I'm not questioning this. I'm questioning the fact that the DSA
allows a client to be happy with using a control with a
criticality that could endanger the data integrity or security
(and, all in all, violates the control's specs).
Also, I understand that rejecting an operation because it was
performed with a non-critical control is in contrast with RFC4511.
Now RFC 4511 does allow for a server to, if it can, process the
operation without the control. But the server certain cannot
process a part the operation with the semantics implied by the
operation and a part without.
Handling of dontUseCopy needs to be fixed in slapd (see ITS#5785)
for conformance with RFC4511, although this would allow slapd to
process a control whose criticality setting is in violation of its
The server is not responsible for odd service if client fails to
mark dontUseCopy critical.
I'm even more concerned about handling of RFC4370, which is now
handled in full conformance of RFC4511, but I'd rather prefer that
slapd rejects it if requested with criticality set to FALSE.
The server shouldn't even consider criticality in its processing
until after deciding not to make use of a control, whether to fail
due or ignore the control.
To me, slapd should reject those cases with protocolError.
This kind of breaks the separation between the controls criticality
processing and control processing.
Yes. But this is a consequence of the fact that some controls'
specs seem to overload the criticality flag with some additional
Though there are certainly one or two such specifications, a spec
which simply says a client MUST specify mark a particular control as
critical does not create such an overload. This is because a client
MUST does not impart any requirement upon the server.