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

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

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?  It seems to me that all that
matters is that it is defined. 

>'defined by a control
>spec' seems a quite reasonable interpretation in this context, but
>that's too strict if we forbid everything else.

Exactly.  Maybe it's implicitly agreed to by the implementors
of the client and server (maybe they are the same implementor).

>Maybe a better distinction is that the implementation should not give an
>ambiguous control combination arbitrary semantics; it should either
>return an error or give it deliberatly chosen semantics.  And perhaps
>error should be RECOMMENDED.

One could argue that it would be impossible to implement
a combination of controls unless the semantics of that
control were defined.  That is, how does one implement
undefined behavior.  And by implementing it, it could be
considered defined.  So maybe we're just splitting hairs
here.

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..

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.

Do implementations actually return protocolError for something
like search+A+B?  Or do they either ignore B if non-critical
or return unavailableCriticalExtension otherwise.

(Note that the above is note intended to be sequence order
dependent, but dependent on the order of examination (not
necessarily processing) by the implementation.

Kurt