RE: appropriateness of combination of controls (new suggestion)

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

At 09:36 PM 5/10/2004, Ramsay, Ron wrote:
>1. I think "appropriate to the operation" is pretty clear.

This discussion is evidence to the contrary.

>To imply appropriate the the operation as modified by controls, you would have to say just that?

I suggest you offer specific text for WG consideration.

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

You imlied this when you said "If you recognise this control
you must honour it".

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

Just a nit: but different servers clearly give different
results even when all controls are marked critical.  I
assume you mean to say that different servers may perform
different operations unless all controls are marked
critical.

>"Cannot controls and combinations of controls be specified
>privately?"
>
>What ACTUALLY does "specified" mean here?

Dictionary definition:
  clearly and explicitly stated

>You can certainly use private controls provately, but this is not an issue for the IETF.

Specification of private control is a private matter, but the
ability to support to support private extensions is an issue
for the IETF.

Whether a specification is privately or openly specified is
not particularly relevant to the question of whether a
control (or combination of controls) is "recognized and
appropriate for the operation".

>Once you "specify" a control, presumably it is no longer private?

No.  Once you "specify" a control, a specification for the
control exists.  Private reflects upon the availability of
that specification, not its existence.

>Or do you mean one scratches a meaning on a table napkin?

If the scratches clearly and explicitly state the meaning,
then that napkin holds a specification of that meaning.

Kurt


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