RE: appropriateness of combination of controls (new suggestion)

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

At 07:08 PM 5/10/2004, Jim Sermersheim wrote:
>So now what is being brought up is the definition of 'appropriate'.

I define "appropriate" here to mean that the semantics of
the operation, as extended by the controls, are understood
(presumably both client and server).  I do not define
"appropriate" to mean that the implementation is willing
and able to perform the operation.

My view on this is that when you have X+A+B, the operation
should be either treated as:
        X extended by A, extended by B,
or:
        X extended by B, extended by A,

and not:
        X extended by A and B.

The former treatment leads to processing consistent with
the client requested (assuming A and B are not critical)
either X+A+B, X+A, X+B, or X is to be performed.  One
of my primary reasons for support this treatment is that
it is consistent with how I believe existing servers
behave.  (Again, I'd very much like to hear from those
with knowledge of servers that behave differently).

The latter approach leads to error which is not easily
recovered from.  If the server doesn't recognize X+A+B,
but does recognize X+A and X+B, the server is forced to
return an error even though server is quite capable of
performing X+A, X+B, or  X.   The error is not easily
recovered from because there is no particular result code
that indicates the nature of this failure.  Hence, the
client cannot realistic be expected to know if it should
reissue the operation less one controls (or both), or
view the server as not being able to perform the
operation as generally indicated whatever error code was
returned.  I am not aware of any servers which
behaves this way.

A few additional comments below:

>I've always had a limited view of what this means * it's either appropriate or not at an operation level.

I view it at the semantic level versus the processing level.
That is, if the server is able to understands the use of
the control, then it is appropriate regardless of whether
the user is willing and able to perform the operation as
understood.

>This has caused confusion though (and not just in the face of multiple controls). For example, it was never known whether it was appropriate to send a persistent search control with a search operation which had a size or time limit specified.

Since the decision is made in the context of a particular
implementation, ambiguity of the control specification does
enter into 'appropriateness' decision.  The decision is
made based upon the servers understanding of the specifications,
as imparted by the developer.  That said, assume that the
specification explicitly stated it when the control was attached,
the size/time limits should be unlimited.  If the client violates
this, I'd argue that this is an error that would commonly be
detected while performing of the operation (as oppose to
determining what operation to perform).

>Servers implemented the behavior in different ways (though I don't think any treat it as inappropriate, and allow a false criticality to cause the control to be ignored).

Right, they treat it as an error detected while performing
the operation.

>So Kurt is just saying, "let's define the term appropriate to mean ...". Since the term has never been defined before, I think it's a worthwhile exercise, if it answers the combination of controls question, then it's even better.
>
>If we are going to say that controls can affect the appropriateness of an operation, then I believe any variable of an operation should be allowed to determine whether the attachment of a control is appropriate.

By variable, I presume you mean protocol field.  If you meant
factor instead, then I would strongly disagree.  With any protocol
field, my concern is that any protocol field might overly complicate
server determination of appropriateness.  I would prefer to
limit determination to consideration of protocolOp and controlTypes.

>Furthermore, it makes sense that if one states that control A is appropriate for operation X, then all variations of operation X are appropriate * one should list the known inappropriate states of an operation's variables, not all permutations of appropriate one. If this is the rule, then clearly we have some control definitions that need to be updated * which is fine.

I would rather treat these controls as appropriate for the
operation, but that the operation is not well formed...
which is what I believe current implementations do.

>I think this may lead to different results from Kurt's suggestion.

I think whatever clarification we make has to lead to
specification which most (if not all) existing implementations
are consistent with.

>If both controls A and B are appropriate for operation X, then neither can be ignored (or error with unavailableCriticalExtension) due to being inappropriate. But if control B states that it is inappropriate to be used on operation X.A, then it (but not A) can be ignored (if criticality is false).  If the specification for B makes a statement regarding the appropriateness of A attached to X.B, it is considered an update to the specification of A.

It would be better to say that this statement is part of
specification of A.  In determination of appropriateness of A,
organization of the specification of A is irrelevant.


>Jim
>
>>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 5/10/04 7:20:15 PM >>>
>Hi Kurt,
>
>I disagree with this because you have changed the control semantics from:
>
>- If you recognise this control you must honour it
>
>to
>
>- You may choose to ignore this control.
>
>In general, I agree with Jim's remarks. Certain control combinations can be specified in RFCs.
>
>However, where a novel combination of controls is received by a server, I think it would be OK for the server to process it, rather than respond in a technical way with an error result. Note that once you specify the a server MUST respond with an error, there is no way to subsequently legitimise the control choice.
>
>On a personal note, I found the whole discussion of 'defined' very silly. Behaviour is either 'specified' in the usual places, or it remains unspecified. It cannot be 'defined' locally. That simply makes each server self-documenting, in a way.
>
>Ron
>
>-----Original Message-----
>From: owner-ietf-ldapbis@OpenLDAP.org 
>[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
>Sent: Tuesday, 11 May 2004 07:45
>To: ietf-ldapbis@OpenLDAP.org 
>Subject: appropriateness of combination of controls (new suggestion)
>
>
>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).
>
>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).
>
> 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.
>
> 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.
>
>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.
>
>  It is noted that semantics of a combination of controls
>  is generally found in the control specification most
>  recently published.  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.  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.