Re: control combination was: Re: protocol-22 comments)

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

In chewing about this more, I'm now thinking that text I suggested
is a bit problematic, mainly because it is at odds with current
implementations.  I am not aware of any implementation which treats
a combination of mutually exclusive controls as a protocol error.
As hinted at in my previous comment, I'm thinking that RFC 2251
actually handles this issue in its use of the term 'appropriate
for the operation'.

I think we need to look at ways of clarify the RFC 2251 text to
note that, in face of sequence of controls which are inappropriate
for the operation, the server is free to either treat the message as not
being well constructed (e.g, protocol error) OR to ignore any
number of the non-critical control so that the remaining controls
are recognized and appropriate for the operation OR, if to
arrive at a sequence of recognized and appropriate controls for
the operation would require ignoring a critical control, to
return unavailableCriticalExtension.

Kurt

Below are a few comments I wrote while chewing on this.  The
above is more reflective of where I am presently at on this issue.
I've attached them as there are a few related or tangential issues
I felt the need to comment on.


At 07:07 AM 5/10/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 12:04 PM 5/9/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>>At 10:39 AM 5/7/2004, Jim Sermersheim wrote:
>>>>> If there are only two cases (defined and undefined), then we need to
>>>>> state what 'defined' means.
>>>> 
>>>> I think we can and should rely on the dictionary meaning of the word.
>>> 
>>> Which shifts the question to: defined by what?
>> 
>> Does it matter how it's defined?
>
>If [Protocol] states what to do about '(un)defind' control combinations,
>it should also clarify what '(un)defined' means, since there are several
>equally reasonable but very different interpretations.

Maybe we need to move away from the term 'defined'.

RFC 2251, when describing message construct/deconstruction, used the
term: "appropriate for the operation".  In this thread, when we said
the semantics of the combination of the controls should be
defined, I think we mean the combination of the controls should
be appropriate for the operation.

Of course, this leads to the question "what's appropriate".
well, that's for the control's specification (whether it written,
or in other form) to say.

>> It seems to me that all that matters is that it is defined. 
>
>Then it's pointless for [Protocol] to specify what to do if a control
>combination is undefined.  As you said below, an implementor could say
>that by implementing it, it could be considered defined.  That reduces
>anything [Protocol] says about it to mere word games, and the
>implementor can simply ignore the paragraph about control combinations.

I think there will always be room for word games.

I think it reasonable for the protocol specification how implementations
are to respond when faced with constructs they do not recognize or they
do not otherwise think are appropriate.

This is completely orthogonal, in my mind, to how and where those
constructs are specified.

>> My view is that an implementation should not attach control
>> A to message X unless A is appropriate for X, that is:
>> X+A has well defined semantics.  And one should not attach
>> B to X+A unless B is appropriate for X+A, that is X+A+B has
>> well defined semantics.  Etc..
>
>Well, yes.  But now you are right back to 'defined' again.

Or back to 'appropriate'.  Note that problem is not just with
combinations, but also with controls when used individually.

What's 'defined'?  What's appropriate?... To this, I say, look
at the (definitive) specification of that construct.  However,
I cannot guarantee that there will a specification, let alone
a definitive specification.

>So I think 'unless ... X+A+B either has unambiguous semantics, or how to best
>resolve an ambiguity has been considered by the implementor' is a more
>useful criterion.
>
>> The processing of X+A+B is complicated by the fact that
>> A or B or both could be non-critical.  I suspect most
>> implementations act as follows on receipt of X+A+B:
>>   is X well formed? if not return protocolError.
>>   is A recognized and appropriate (for X)?
>>      If not and critical, return unavailableCriticalExtension
>>      If not and non-critical, ignore A
>>      Otherwise, is A well-formed?  If not return protocolError.
>>   is B recognized and appropriate (for X or X+A, depending on above)
>>      If not and critical, return unavailableCriticalExtension
>>      If not and non-critical, ignore B
>>      Otherwise, is B well-formed?  If not return protocolError.
>
>Good point.  However, we'd get more predictable results (for someone who
>does not known the particular implementation) if the implementation
>ignores all non-critical controls which are incompatible with some other
>control in the message.

I argue that more predictable results are not desirable here.  If a
set of controls are marked non-critical, then no real harm is by the
server ignoring any subset (including complete and empty sets) of the
controls.  I would argue instead that it more desirable to have the
implementation do "best effort" processing.

But note that I was attempting to describe what is the currently
implemented behavior.  My concern with "MUST treat as protocol error"
is that this isn't what current implementations behave.

>Maybe implementations MAY ignore selected
>non-critical controls that conflict with other controls,

RFC 2251 actually said:
   If the control is unrecognized or inappropriate but the criticality
   field is FALSE, the server MUST ignore the control.

If a non-critical control conflicts with some number of other controls,
the non-critical control may be viewed as inappropriate.  If so, it
MUST be ignored.

>and SHOULD if
>so ignore _all_ non-critical controls that conflict with some other
>controls?

Besides that not being what implementations do today, I don't see your
reason for this imperative as enough justification for the SHOULD.

>OTOH, we are talking about control combinations that either
>fail or are unpredictable in any case, so maybe not...

Note that I am not talking at all about the performance of the operation
as extended by the controls (e.g., which might fail or be unpredictable),
but whether the message is well constructed and its semantics are clear.

>One other detail: I don't think it fits the definition of protocolError
>in section A.2 to return that for a control combination which MAY be
>treated either as defined or undefined:
>        protocolError (2)
>           Indicates the server received data which has incorrect
>           structure.
>If servers are to return protocolError for such control combinations,
>that must be added to the list of exceptions to the basic definition of
>protocolError in A.2.

I think, 'incorrect structure' is meant to broadly refer to
any invalid construct.

>I already dislike the length of that list, though.  Maybe
>unwillingToPerform or unavailableCriticalExtension is better.

Both of these, in my opinion, are inappropriate here.

The question of willingness to perform of an operation is generally
made after one de-constructs the message semantics.  While certainly
a server could be unwilling to de-construct (parse) the message,
this should not be confused with a de-construction error.

And, unavailableCriticalExtension is only applicable where the
unrecognized and inappropriate control is critical.