Subject: Re: appropriateness of combination of controls (new suggestion)

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 14 May 2004 10:56:46 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 May 2004 20:04:20 -0700

The semantics of most combinations of controls are unspecified.
While I would agree that existing implementations do implement
some combinations of controls whose semantics are unspecified, I
hope they have done so only after fully considering the implications.
In particular, I would hope servers only viewed a control
appropriate for the operation if the semantics of the operation
(as extended by that and other controls) were clear to the
implementors of the server and the clients the server was intended
to interact with.

I believe that existing implementations, when faced with a
combination of two non-critical controls they believe to have
mutually-exclusive semantics, will ignore one or both of the
controls instead of failing the operation.  It's my view this is
what RFC 2251 intended servers to do when it repeatedly used the
language "appropriate for the operation".  (If you know of servers
which behave differently, I'd be interested in details.)

My view is that the most reasonable answer to:
  When is a control "appropriate for the operation"?
is:
  When the specification of the control states that it is.

The question as to whether a particular specification is clear
enough and/or explicit enough it this statement, or otherwise
adheres to current practices, should be discussed in review of
document detailing it... and possibly as part of a review of
a document detailing best current practices in this area.
(And where we find existing specifications not to be up to
snuff here, we should revise them.)

At 09:56 AM 5/14/2004, Jim Sermersheim wrote:
>I think we're getting overly wordy with all this.

Though you said this in a particular context, I believe it applies
generally here.  I'm going to try to produce a less wordy text.