RE: appropriateness of combination of controls (new suggestion)

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

At 07:24 AM 5/11/2004, Hallvard B Furuseth wrote:
>> Dictionary definition:
>>   clearly and explicitly stated
>
>As I've mentioned several times in this discussion, the point is:
>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.

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

>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.  And I find your suggestions to be a bit
confused.

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


>>> -----Original Message-----
>>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>>>> 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").
>
>That was not about private controls, but about local - or private -
>definitions of control combinations that the control specs leave
>undefined.
>
>-- 
>Hallvard