Re: Protocol: control specifications.

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

John, Hallvard,

Are you aware of any server implementation which behaves consistently
with the interpretation that you and Hallvard favor?  Is there any
existing clients which relies on this behavior?

If not, I don't think it makes sense to make a change which require
changes to be made to most (if not all) servers, especially where
those changes would cause breakage between pairs of interoperating implementations.

I think the suggested new text is pretty clear that if a control
specification really needs to alter the semantics of the server's
general criticality processing, the control specification needs
to state an imperative separately from the guidance it gives to
client.   That imperative would logically be part of the control's
semantics as it is semantics associated with a particular control
type.

Changing the 'core' TS to say that a "criticality MUST be TRUE"
implies both a requirement on the client and a requirement upon
the server is quite problematic as there are numerous control
specifications in existence which said this but intended that
statement to apply only to the client.

I know of know control specification which stated "criticality
MUST be TRUE" which intended that statement to apply to servers
nor am I aware of any server implementation which took such a
statement as applying to them.  Do you?


At 07:22 AM 1/13/2004, John McMeeking wrote:
>After further discussion here, I side with Hallvard.  There are likely to
>be cases where the behavior of a control is such that it really ought to be
>marked critical because the outcome when used with a server that doesn't
>support the control is clearly undesirable.  To the end user, it is little
>consolation that the application they are using is at fault because it
>neglected to mark the control critical.
>
>I haven't come up with an argument that a control must have
>criticality=FALSE to prevent similar situations, so I suggest we get rid of
>the "criticality always set to FALSE" part.
>
>To make it clear that "criticality MUST be TRUE" is a requirement to both
>the client and server and to avoid confusion (I hope) with previous
>guidance that criticality always be set to TRUE, I suggest a specific RFC
>"MUST" clause that can be used in future control specifications.  I don't
>believe current control specification have such language, so there should
>be no compatibility issue.  Support for a new control generally requires
>some sort of server change; support for a new control could include a
>mandatory criticality check.
>
>That leaves control criticality options as:
>- critical at senders choice, with a recommended criticality in the control
>specification, or
>- criticality MUST be TRUE
>
>I suggest that we update protocal 4.1.11 as follows.
>
>1) add the following text somewhere in 4.1.11:
>
>   A control specification MAY state that "the control criticality MUST be
>TRUE."
>   If a control is defined in this way and the sender's control criticality
>is
>   FALSE, the server MUST return protocolError. If a specification does not
>   state that "the control criticality MUST be TRUE" the sender's control
>   criticality is used.


This would change the interpretation of existing specifications
in a manner which was intended by their authors nor implemented
by previous readers, and this would lead to breakage.


>2) update the guidance to control specification writers:
>
>   The specification of a control consists of:
>
>   ...
>
>   - a recommended control criticality, or a requirement that the control
>     criticality MUST be TRUE.

A control specification needs to provide adequate guidance.
Beyond that, if a control specification wants to change the
general semantics of the any protocol field, it should do
so in its text which details the semantics of the extension
information carried in the control.

I have prepared replacement text for the whole section
for the WG to consider.  I'll be posting it separately.



>John  McMeeking
>
>
>"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote on 01/09/2004 10:11:02 PM:
>
>> At 12:55 PM 1/9/2004, John McMeeking wrote:
>> >X.511 has a similar notion of recommended criticality.
>>
>> Similar or same?  Given that one of planned uses of LDAP
>> Controls was to provide a mechanism in which additional
>> X.511 semantics could be added to LDAP in a manner which
>> would facilitate implementation of LDAP<->X.511 gateways,
>> I think the intent was for the criticality semantics to
>> be the same.
>
>Yes, I could have used "the same".
>
>>
>> X.511:
>>    The criticalExtensions component provides a mechanism
>>    to list a set of extensions which are critical to the
>>    performance of a Directory operation. If the originator
>>    of the extended operation wishes to indicate that the
>>    operation shall be performed with one or more extensions
>>    (i.e. that performing the operation without these
>>    extensions is not acceptable), it does so by setting the
>>    criticalExtensions bit(s) which corresponds to the
>>    extension(s). If the Directory, or some part of it, is
>>    unable to perform a critical extension it returns an
>>    indication of unavailableCriticalExtension (as a
>>    ServiceError or PartialOutcomeQualifier). If the Directory
>>    is unable to perform an extension which is not critical,
>>    it ignores the presence of the extension.
>>
>> Sounds the same to me.
>>