Re: Protocol: control specifications.

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

Hallvard,

I believe you are missing a few aspects of the RFC 2251 text:
   This document does not define any controls.  Controls may be defined
   in other documents.  The definition of a control consists of:
     ...
     - whether the control is always noncritical, always critical, or
       critical at the client's option,

Note that the bullet is part of a statement of practices to be followed
in writing extension documents.  That is, this bullet is not stating a
requirement upon implementations of LDAP (including those implement
any control).  Someone implementing LDAP can completely ignore this
paragraph as it simply does not pertain to implementations.

Second, your interpretation of this text as an implementation requirement
is counter to the previous text detailing the protocol:
   The criticality field is either TRUE or FALSE.                      
                             
   If the server recognizes the control type and it is appropriate for
   the operation, the server will make use of the control when
   performing the operation.

This text, as been interpreted by most implementors as meaning that,
regardless of the value of criticality presented, a server is to make use
of a control when they recognize the control type and that control type
is appropriate for the operation.

You suggested text is also problematic for a number of reasons:
        1) servers don't, as far as I know, don't behave in the manner you
        describe,
        2) the suggestion is counter to "be liberal in what
        they accept" principle, and
        3) the suggestion hinders changes to guidance given (based upon
        operational experiences or otherwise).

Your primary argument to make the change is that servers should check
user input.  I think it can be reasonable be argued that checking user
input in this case is primarily the responsibility of the client (under
the clients "should be strict in what they send" principle).

I oppose the direction you suggest we take.

A few additional comments below.

At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> Though I think you might have misunderstand some of my points,
>> I likely some of yours, and that we're not exactly seeing eye to
>> eye on the "why", I think we've converging on acceptable
>> replacement text.
>
>I don't:-(
>
>> Here is my latest offering:
>> 
>> - guidance as to what value the sender should provide for the
>>   criticality field
>
>That still has the problem that it removes the server's license to
>treat the 'unadvised' criticality as an error.

Again, the RFC 2251 text which this replaced does not specify any
implementation "license" as it simply did not pertain to implementors.
Was a profiling statement for extension specifications, as is the
replacement text.

>In that, it goes
>exactly in the opposite direction of what I want.  My preference is
>this text from protocol-19:
>
>   - whether the criticality field should be always set to TRUE,
>     always set to FALSE, or sender's choice

As previously noted, this language could be viewed as limiting the
kinds of guidance which an extension specification could give.  For
instance, it does not allow an extension from saying:
        Criticality should be TRUE when X is TRUE.
or
        Criticality should be FALSE when Y is FALSE.

The intent of this original text was to encourage extension authors
to discuss the circumstances of when particular criticality values
are appropriate.  The text I proposes attempts clarify the text
to that intent while removing ambiguity that some have raised that
the text could be viewed as stating an implementation requirement
(instead of a document profile). 

>Failing that, my second suggestion would be to revert to RFC 2251's
>text:
>
>   - whether the control is always non critical, always critical, or
>     optionally critical, 
>
>which at least won't introduce any incompatibility.
>(Or s/optionally critical/sender's choice/, I liked the new phrase
>better.)

The original text has most of the same problems as your suggested
text.

>Also, I'm still hoping for:
>
>  If the criticality field for a supported control does not match
>  the value required by the control specification, the server SHOULD
>  NOT perform the operation, but instead return protocolError in the
>  resultCode if the operation has a response.

It would be inappropriate to make such a statement in text intended
to detail a document profile.  When considers this as an addition
to the technical specification, absent the document profile, it becomes
clear that you are asking for a change in protocol semantics.

>or s/required by/in/ if we use the RFC 2251 text above.
>
>>   (note: the processing semantics of the
>>   criticality field, which are defined above, should not be
>>   altered in any way by the control's specification),
>
>I'd strengthen that:  s/should not/can not/.  Remove '(note: )'.
>(Yes, I know.  Nobody is as fanatic as a convert:-)

I think it clearer as suggested.

Kurt