RE: appropriateness of combination of controls (new suggestion)

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

At 05:15 AM 5/12/2004, Hallvard B Furuseth wrote:
>OK, then ignore my complaints about ambiguity in your latest offered
>text.

okay.

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

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.

>Except, a later part of your reply makes me wonder whether or not that's
>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.

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

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

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

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.

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

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.

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

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

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

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.

>>> 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.
>>
>> Well, the wording is intended to discourage local semantics,
>> but encourage (privately or openly) specified semantics.
>
>That's fine, but irrelevant to my point.
>
>>> Why do you keep insisting on ambiguous or even misleading wordings
>>> 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.
>
>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.

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.

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

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.

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

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