RE: appropriateness of combination of controls (new suggestion)

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

1. I think "appropriate to the operation" is pretty clear. To imply appropriate the the operation as modified by controls, you would have to say just that?

I can't understand

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

- did I say that??

It is certainly clear that different servers will give different results, unless all controls are marked critical. Fact.

"Cannot controls and combinations of controls be specified
privately?"

What ACTUALLY does "specified" mean here? You can certainly use private controls provately, but this is not an issue for the IETF. Once you "specify" a control, presumably it is no longer private? Or do you mean one scratches a meaning on a table napkin?

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 11 May 2004 13:11
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: appropriateness of combination of controls (new suggestion)


At 06:20 PM 5/10/2004, Ramsay, Ron wrote:
>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.

>to
>- 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 makes each server self-documenting, in a way.

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