Re: appropriateness of combination of controls (new suggestion)

["Jim Sermersheim" <jimse@novell.com>]

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/14/04 12:00:53 AM >>>
<snip>

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

Right.

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

Yes.

>In
>more recent specifications, specifications also include statements
>regarding use with other controls, which implies an appropriateness
>for operations extended by these other controls.

No. This doesn't imply appropriateness to me (or anyone else I've seen contribute to this thread other than you). I believe there are specifications which specify interactions with other controls, but I don't believe they instruct (either explicitly or implicitly) the combination with other controls to be treated as inappropriate. To me, this concept is a new feature. 

Furthermore, I believe these specifications are simply documenting semantics for combinations with other controls which are known have interesting effects on the operation. They completely ignore other controls which may fall into either category of benign and allowed, or crazy and impossible. Maybe I need to read more control specifications, can you provide references?

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

Again, I'll echo that my interpretation says this is a new feature * I'm fine with it as long as the WG is.

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

Why is protocolError more appropriate than any other error? Elsewhere we say that a malformed message can cause this error. Are you saying that certain control combinations can be treated as a malformed mesage?

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

Any sequncing is also a combination. I mean sequencing is a superset of combining. If 'sequencing' is not informative enough, we can add informative redundancy by /s/sequencing/combination or sequencing.

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

Yuk. This just opens the door for my recently commented on worries to become reality. It's well-enough known in the IETF that an RFC can update in whole or in part another RFC, so I don't think this is needed. I think we're getting overly wordy with all this.

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

If a specification (like that of ManageDsaIT) says nothing of its combination with other controls, and other controls don't mention ManageDsaIT as a valid control to be combined, implementors will (and do) allow its combination. What I'm trying to say is that unspecified control combinations like this that actually get passed to LDAP servers will most likely be sane, and very appropriate (though not specified). Thus, implementations will do just the opposite of this statement. They will generally allow these combinations.

This is why I prefer to turn this whole around. If a specification says Control A is appropriate for Operation X, then it is allowed for all permutations of Operation X (unless some other specification disallows it). Then we would allow implementations to disallow combinations that are not understood, but suggest that this begs for an update of one or more of the problem controls.

>('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).

Yes, and this will always be a problem unless we forbid it * which is probably going too far. But by not forbiding it, and by adding the proposed language, all we've really done is to add a new feature that lets servers ignore non-critical controls in a combination even though they would process that control otherwise.

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

I'm not sure I see the problem you are stating here.

<snip>

Jim