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

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 11 May 2004 11:20:15 +1000

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Tuesday, 11 May 2004 07:45
To: [email-masked]
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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 May 2004 20:10:39 -0700

>I disagree with this because you have changed the control semantics from:

I argue that I am only clarifying what "appropriate to
the operation" means, a phrase which wasn't well defined
in RFC 2251.

>- If you recognise this control you must honour it

RFC 2251 actually said "recognized and appropriate for the
operation" and directed the server to ignore non-critical
extensions which were not appropriate for the operation.

>- You may choose to ignore this control.

Based upon whether the control is appropriate or not.   But if
it is appropriate, then server must "make use" of the control.

The issue comes down to "what did RFC 2251 mean when it
said 'appropriate to the operation'?".

I agree that 'appropriate' did not mean "server is willing to
perform" (as we've discussed on this list previously).  But I
disagree that 'appropriate' was simply a question of whether
the control was specified for use with the message it was
attached to.  I argue that 'appropriate' also encompasses
whether the control is used in a combination specified for
use with the operation.

That is, "appropriate to the operation" means more than
merely "attached to an appropriate message".  The server
has to consider how the control is used in total, not
just itself.

I believe this is precisely how server implementors have
interpreted RFC 2251.  I would be interested to hear if
anyone has knowledge of a server returning an error for
a request which contains a pair of mutually exclusive,
but otherwise appropriate, controls.  VLV+PagedResults,
LCUP+PersistentSearch, LCUP+LDAPSync, ...  If they do
return an error, which error do they return.  And how do
they distinguish use that code from its normal meaning.

>In general, I agree with Jim's remarks. Certain control combinations can be specified in RFCs.

Cannot controls and combinations of controls be specified
privately?

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

If the server is able to "make use" of the combination,
the I'd argue that the server must have recognized each
control and believed not only the individual controls
were appropriately attached to the message, but believed
that the combination of controls was appropriate for the
operation.

I find it odd however that you suggest that while one server
can perform X+A+B, but that another server cannot perform X+A
(finding that X+A+B is not appropriate for the operation)
simply because it happens to recognize and find appropriate
X+B (or vice-versa).  While a server which recognized only
X+A or only X+B could process that.

>Note that once you specify the a server MUST respond with an error, there is no way to subsequently legitimise the control choice.

My current suggestion doesn't mandate an error response.

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

I didn't mean to imply the semantics could be locally defined,
but that they can be privately defined.  While a private control
may be defined in terms of an implementation (e.g., "The semantics
of the X control are as implemented in server Y."), but that's
quite different from saying the defined locally (e.g., "The
semantics of the X control are local to the implementation").

Kurt