If the client needs to know that there support for the control, doing so by altering the flow of the protocol is not the way to do it, particularly when the change in flow is unrelated to the mechanism that caused it. The client should examine the root DSE entry for supported controls, and should be able to expect the same behavior whether it marks the control critical or not. Marking a control non-critical implies a level of indifference as to whether its function is understood and performed and I fail to see the need to inform those who are indifferent.Hmmm. I didn't think the control was required to be marked 'critical'
from <draft-behera-ldap-password-policy-09>
The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may be TRUE or FALSE. There is no controlValue.
but, if it is, then you are correct that the control will have been
recognised if the request was performed. (Your remark "when the control
is not critical" makes me believe that you don't understand the use of
the criticality flag. For example, you cannot respond with
"unavailableCriticalExtension" if the control is not marked critical.)
I believe I understand it. That's why I agree that if no criticality was set in the request, a control response with no value should be sent to clarify that the DSA understood the control.
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext