Re: Protocol: control specifications.

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

The current language regarding extension document guidance to
criticality is still problematic:
>   - whether the criticality field should be always set to TRUE, always
>     set to FALSE, or sender's choice, and server behavior when        
>     constraints of this nature are violated,

As I previously suggested:
> Consider the need to update a specification from "clients MUST provide
> criticality field of TRUE" to "clients SHOULD provide criticality field
> of TRUE".  Such a change could not be made if we require servers to
> error where the criticality is not TRUE.
>
> Control specifications should detail under what circumstances the
> control generator should mark the control critical or non-critical.
> However, they should not detail any semantics upon the implementation
> processing that control as those are defined in the general protocol
> semantics. 

I offer the the following replacement text:
    - guidance as to what value should be provided for the criticality      
      field,

and, given the past problems with control specifications
adding semantics to the criticality flag, I suggest the
following note be added as well to this bullet item:
    (the processing semantics of the criticality field, defined above,
    should not be altered in any way by the control specification)