RE: appropriateness of combination of controls (newsuggestion)

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi,

I have a bit of trouble with all this. See <RR> inline.

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim
Sent: Friday, 14 May 2004 15:05
To: ietf-ldapbis@OpenLDAP.org; Kurt@OpenLDAP.org
Subject: Re: appropriateness of combination of controls (newsuggestion)


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

<RR> The statement imposes no requirements so it is of little consequence.

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

<RR> If you are going to allow the server to choose which controls it will honour, then you have broken the rule that ANY control that is recognised, must be performed. This seems like a small step for one man but a giant leap for mankind.

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

<RR> It doesn't matter what the client does. This issue is just silly.

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

<RR> What is meant by 'published'? A previous thread rattled on about controls being specified on napkins. Surely having specified a control on a napkin you must now specify how it can be used in conjunction with other controls on a napkin. In fact, on the SAME [RFC 2216] napkin.

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.

<RR> Surely any implementor could write the required semantics on a napkin?

>  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