RE: appropriateness of combination of controls (new suggestion)

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

So now what is being brought up is the definition of 'appropriate'.

I've always had a limited view of what this means * it's either appropriate or not at an operation level. 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. 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).

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. 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 think this may lead to different results from Kurt's suggestion. 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.

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.