Re: appropriateness of combination of controls (new suggestion)

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

At 10:05 PM 5/13/2004, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/10/04 3:45:13 PM >>>
>>I offer the following for WG consideration:
>>
>>0)  Add to end of the first paragraph of 4.1.11.
>> Implementations SHOULD only attach controls which are
>> appropriate for the operation (as discussed in applicable
>> specifications).
>
>yes
>
>>1) Insert new paragraph above the one which starts with
>>"The controlValue may contain information":
>>
>> When considering whether a control is appropriate for the
>> operation, the implementation is not only to consider whether the
>> control is attached to a message it was intended to be used
>> with, but whether the control is being used appropriately
>> in combination with other controls (of same or different
>> controlType).
>
>To me, this goes beyond the general understanding of the wording in
>RFC2251, but not so far as to allow operation appropriateness to
>consider things that likely should have been controls in the first place
>(size & time limits, alias dereferencing). But if no one else in the WG
>cares, I'll stop raising the issue.

I think there has been an understanding that "appropriate for the
operation" was a something that was straight forward to determine
and, in particular, didn't involve "performing the operation".
In most existing specifications, that was generally stated in
terms of the kinds of LDAPMessages (by protocoOp and, if appropriate,
request/response name) the control was appropriate for.  In
more recent specifications, specifications also include statements
regarding use with other controls, which implies an appropriateness
for operations extended by these other controls.

Maybe future control specifications will state appropriate in other
terms.  Maybe that's an issue for these specifications to deal with.

I think it important that [protocol] deal more explicitly
with combinations of controls and, in particular, that determining
whether a control is "appropriate for the operation" involves
consideration of what other controls which might be present.

>> When a server is faced with a sequence
>> of controls which are not appropriate for the operation,
>> the server may attempt, by ignoring any number of
>> non-critical controls (including controls whose criticality
>> field is to be ignored as discussed above), a sequence which
>> is appropriate for the operation.  If such a sequence is found,
>> the server is to make use of it when performing the
>> operation.  Otherwise, servers are to fail the operation
>> and, and for operations which have a response, indicate so by
>> returning unavailableCriticalExtension (if any of the controls
>> were marked critical) or protocolError (if the message is
>> considered not well structured) or other appropriate result
>> code.
>
>The statement about protocolError and other appropriate result code is
>redundant and not needed here, otherwise, this fits well with the
>intended flow started above.

I called out the these two codes (unavailableCriticalExtension
and protocolError) as they are to most appropriate to return here.
Most other codes indicate problems found during performing the
operation.  However, I didn't want to restrict servers to just
these two codes.

>> When a client is faced with a sequence of controls which
>> are not appropriate for the operation, the client may
>> attempt, by ignoring any number of controls, in order
>> to make use of the response in its processing.  Alternatively,
>> the client may treat the response as not well structured.
>
>I'm not exactly sure why this is needed, but I also can't see that it
>detracts from the specifiecation.

I added this for completeness.


>>2) Remove the existing paragraph which starts with "Controls SHOULD
>NOT
>>be combined".
>>
>>3) Replace as last bullet with:
>>       - optionally, semantics regarding combination of the
>>       control with other controls (of same or different
>>       controlType).  These semantics may rely on ordering
>>       of the controls in the sequence of controls attached
>>       to the message.
>
>or how about:
>- optionally, semantics regarding the sequencing of this control with
>other controls (of same or different controlType)

Because the semantics of the combination may not be in regard
to the sequencing of this control with others.

>>  It is noted that semantics of a combination of controls
>>  is generally found in the control specification most
>>  recently published.
>
>ok

In response to Hallvard's comments, I suggested added something
like:
        , but may be separately specified.


>>  In absence of a specification of
>>  a control combination semantics, implementors should
>>  generally regard use of the control in combination
>>  with other controls  as not appropriate for use in the same
>>  operation. 
>
>Depending on the popular controls de jour, 'generally' likely does not
>reflect reality.

I think it reflects how specifications should be interpreted.
While I would agree that implementations generally have
read into specifications semantics which was not explicitly
stated, implementators should not do that.

('should not' here implying unless they fully understand the
implications of doing so, including likelihood that other
implementors will read in other semantics and that specification
may later be updated to explicitly state different semantics).

>For example, clients that combine controls today are
>likely only combining controls which work just fine together (e.g.
>manageDsaIT + other).

And clients may not interop when clients which implement whatever
semantics are subsequent added to the manageDsaIT specification
in this area.

>It's probably more fitting to /s/should generaly/may here.

I disagree.

>>  In presence of a specification which does not
>>  detail any order dependent semantics, the implementor is
>>  to regard the semantics as being independent on the
>>  order of controls.
>
>yes.
>
>Jim