RE: appropriateness of combination of controls (new suggestion)

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 07:24 AM 5/11/2004, Hallvard B Furuseth wrote:
>>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.

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:

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

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

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

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.

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

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

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

-- 
Hallvard