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

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

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:[email-masked]]
Sent: Tuesday, 11 May 2004 13:11
To: Ramsay, Ron
Cc: [email-masked]
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

---

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

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.

>X+A or only X+B could process 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.

>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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 May 2004 16:24:48 +0200

>> would have to say just that?

Actually, it's "the operation as modified by the controls picked by the
server (from the controls in the LDAPMessage)".  That does look rather
different from the two interpretations of rfc2251 which seem most
obvious to me: the LDAPMessage without controls, or the LDAPMessage with
all its controls.  Though I don't mind the change, if it is a change.

>   clearly and explicitly stated

As I've mentioned several times in this discussion, the point is:
Specified (or previously, defined/documented) by what?  By the control
specs, or also by the implementation (when the control specs say
nothing about the combination)?

> appropriate for the operation".

If you mean that an implementation may privately define a control
combination as being appropriate when their control specs say nothing
about the combination, that's good (but see below).  But it is not the
natural way to interpret the wording you offered, so implementors who
want to do this may believe they are not allowed to, and client
implementors may trust servers to obey the "wrong" interpretation.
Why do you keep insisting on ambiguous or even misleading wordings
about this?  I've offered several suggestions of how to clarify.

On the other hand, with this interpretation, any recommendation to
return a failure for bad control combinations effectively disappears.
I thought that was a major point of what prompted this discussion.

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

That was not about private controls, but about local - or private -
definitions of control combinations that the control specs leave
undefined.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 11 May 2004 09:12:02 -0700

At 07:24 AM 5/11/2004, Hallvard B Furuseth wrote:
>Specified (or previously, defined/documented) by what?

Answer: by a specification.  (This answer is purposely circular.)
And as I responded, I don't see how it matters to this text
what form the specification takes.

To the server making the appropriate determination, what matters
is the knowledge of appropriateness of controls and combination
of controls for operations.  While certainly the developer might
care what, why, where, who questions about specifications in
determining whether to implement a particular specification,
once the developer chooses to implement that specification,
the developer then codes the server with the knowledge of
appropriateness that specifications indicates the server
should have.  The server should then act on that knowledge as
described in the text.

>By the control specs, or also by the implementation (when the
>control specs say nothing about the combination)?

Well, the latter can be viewed as implied that the specification
is a local matter and, I as I noted before, that not my intent.

I would say the former.  But note that I do not equate
"specification" with "document" (and, in particular, with RFC).
The "specification" may be organized as multiple documents, or
as I indicated in response to Ron, might be made on the back of
a napkin, or stated in wide variety of other mediums.

>about the combination, that's good (but see below).

Privately, not locally.  The distinct is that locally implies that
the client is unaware of the server's semantic, privately implies
that the client and server have a private agreement of the semantic...
and that implies that a specification of those semantics exists.

If we assume that the semantics of the combination of two controls
could be specified independently of two control specifications, then
certainly it would be possible for the specification of those
semantics could be private (even though one or both of the control
specifications weren't).  Even if we explicitly state semantics
of combinations are part of the specifications of the controls
involved, some one could privately extend those specifications.

That is, no matter how you word it, implementors can play word games.

Our goal should be produce a wording that doesn't require
word games to do generally acceptable things, and is reasonable
clear that word games are being played when unacceptable things
are done.  That's easier said than done.

>But it is not the natural way to interpret the wording you offered, so implementors who want to do this may believe they are not allowed to, and client

Well, the wording is intended to discourage local semantics,
but encourage (privately or openly) specified semantics.

>about this?  I've offered several suggestions of how to clarify.

In my mind, I suggesting language which I believe is not ambiguous
and not misleading.  And I find your suggestions to be a bit
confused.

>I thought that was a major point of what prompted this discussion.

That might have been what prompted the discussion.  I am about to
post a message in response to Jim's comment which highlights some
of the problems with recommending (or mandating) return of failures
in such cases.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 May 2004 14:15:02 +0200

> what form the specification takes.

I didn't mean the _form_ of the spec (if you still mean 'written
vs. something else' with 'form'), though that can come into play too.
Hm.  I seem to have hijacked the question from Ron:-)
Anyway, I meant what I said in the sentence following that question:

> I would say the former.

OK, then ignore my complaints about ambiguity in your latest offered
text.

But now we are back to the problem of controls that are quite reasonable
to combine, and which were OK to combine by rfc2251, but no longer may
be combined.  E.g. Sort+SignedOp or Sort+ManageDSAIT.  (Well, the server
can ignore one of them if it is not critical, but it may not implement
the combination.)  I think that's wrong.

Except, a later part of your reply makes me wonder whether or not that's
what you mean anyway, see below.

> But note that I do not equate

That's OK with your current meaning.  The "form" of a spec only seems
relevant if [Protocol] says that how the implementation may combine two
controls depends on whether or not there is a spec for the combination,
and that the implementation may specify how to combine two such controls
(whose control specs do not say how to combine them).

> involved, some one could privately extend those specifications.

That's what I want to nail down: Given two preexisting control
specifications, may or may not the implementation (or something else,
for that matter) specify how to combine them - when the two control
specs do not themselves say anything about it?  A moment ago I thought
you meant 'no', but your above text seems to say 'yes'.

I do not want [Protocol] to say that servers should behave differently
depending on whether or not a combination is specified, unless it also
makes clear whether or not the implementation may add such a
specification of the control combination.

> That is, no matter how you word it, implementors can play word games.

Only where the standard makes several interpretations possible, or at
least reasonable.

> are done.

Exactly.

> That's easier said than done.

True, but it will be a lot easier if we just _clarify whether or not the
implementation may privately specify how to combine predefined
controls_.

>> But it is not the natural way to interpret the wording you offered,
>> so implementors who want to do this may believe they are not allowed
>> to, and client implementors may trust servers to obey the "wrong"
>> interpretation.
>

That's fine, but irrelevant to my point.

> and not misleading.

No, it doesn't look ambiguous.  It looks like it means the two control
specifications for two controls are the complete specification of how to
combine them.  It's just that you keep implying that this is not what it
means.  If so, it _is_ ambiguous.

> And I find your suggestions to be a bit confused.

Maybe you confused the 'form' of the specification with whether or not
the implementation may add to previously existing specifications?  Or
maybe because I was confused about what was intended with the wordings I
suggested clarifications for.

> of the problems with recommending (or mandating) return of failures

Yet your text - with the most natural interpretation - mandates failure
for 'unspecified' combinations of critical controls, since the
combination must be deemed inappropriate and therefore must fail.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 May 2004 07:48:57 -0700

>OK, then ignore my complaints about ambiguity in your latest offered

okay.

>the combination.)  I think that's wrong.

It's proper if the semantics of those combination are not clear to it.
Maybe the developer wasn't able to read between the lines.

>what you mean anyway, see below.

What I tried to do was separate what implementations are to
do when they have knowledge that a combination is inappropriate
from who the implementor should interpret specifications necessary
to code knowledge into the implementation.

The first part of the section is talks about implementations,
the second part talks about making of specifications, and
the last part talks about interpretation of specification.

>(whose control specs do not say how to combine them).

What matters to the developer (who has to code the implementation
with knowledge of appropriateness) is whether the semantics are
clear.  To that end, those semantics should be specified (clearly
and explicitly stated).  In some cases, they may not be.  This why
the guidance to the developer is "should generally" instead of
"are to always".

>you meant 'no', but your above text seems to say 'yes'.

Any person can specify (clearly and explicitly state) what the
semantics are, in either a private or open specification.  Once
a specification of those semantics has been made, developers
may code knowledge of those semantics into implementations and,
hence, implementations can support those semantics.

>specification of the control combination.

I think we need to discourage separate specification of combinations
from the controls involved in those combinations.  The current
text tries to encourages a particular placement.  It certainly
doesn't preclude other placements.

>Only where the standard makes several interpretations possible, or at

By 'word games', I presume you mean an unreasonable interpretation.
Unreasonable interpretations are always possible.

>implementation may privately specify how to combine predefined

I could live with (adding a however to my previous suggestion).

  It is noted that semantics of a combination of controls
  is generally found in the control specification most
  recently published, however they could be separately
  specified.

I rather avoid discussion of private v. open specifications.

>combine them.

Guess you missed the word 'generally' used in the text that
describes were a developer can find the specification of the
control combination semantics.

>It's just that you keep implying that this is not what it
>means.

Yes, I mean 'generally' when I said it.

>If so, it _is_ ambiguous.

No, the language I used was not ambiguous as to its meaning.

Yes, I didn't say where all specifications of these kind of
semantics can be found.  I assume it is obvious that they
can be found in the universe of specifications.  As it
should be obvious that all specifications can be found in
the universe of specifications, I don't see any point in
stating that explicitly.

>the implementation may add to previously existing specifications?
>Or maybe because I was confused about what was intended with the wordings I

I find you use of language that implies an implementation can
create and/or revise a specification to be quite odd.

Humans create and revise specifications of semantics
Humans create and revise implementations of those semantics based
   upon their interpretation of the specifications.

>combination must be deemed inappropriate and therefore must fail.

If the semantics of the combinations are not specified, how
could a human implement them?  And, if the combination was
implemented, then would not that imply that semantics must
have been specified?

Kurt