Re: appropriateness of combination of controls (new suggestion)

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

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

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

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

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

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

ok

>  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. For example, clients that combine controls today are
likely only combining controls which work just fine together (e.g.
manageDsaIT + other). It's probably more fitting to /s/should
generaly/may here.

>  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