Re: control combination was: Re: protocol-22 comments)

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

Kurt D. Zeilenga writes:
>At 12:04 PM 5/9/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 10:39 AM 5/7/2004, Jim Sermersheim wrote:
>>>> If there are only two cases (defined and undefined), then we need to
>>>> state what 'defined' means.
>>> 
>>> I think we can and should rely on the dictionary meaning of the word.
>> 
>> Which shifts the question to: defined by what?
> 
> Does it matter how it's defined?

If [Protocol] states what to do about '(un)defind' control combinations,
it should also clarify what '(un)defined' means, since there are several
equally reasonable but very different interpretations.

> It seems to me that all that matters is that it is defined. 

Then it's pointless for [Protocol] to specify what to do if a control
combination is undefined.  As you said below, an implementor could say
that by implementing it, it could be considered defined.  That reduces
anything [Protocol] says about it to mere word games, and the
implementor can simply ignore the paragraph about control combinations.

So if we are going to say something about control combinations, I'd
prefer other - or additional - criteria to defined/undefined.  As my
suggestion below:

>> Maybe a better distinction is that the implementation should not give an
>> ambiguous control combination arbitrary semantics; it should either
>> return an error or give it deliberately chosen semantics.  And perhaps
>> error should be RECOMMENDED.


> My view is that an implementation should not attach control
> A to message X unless A is appropriate for X, that is:
> X+A has well defined semantics.  And one should not attach
> B to X+A unless B is appropriate for X+A, that is X+A+B has
> well defined semantics.  Etc..

Well, yes.  But now you are right back to 'defined' again.  So I think
'unless ... X+A+B either has unambiguous semantics, or how to best
resolve an ambiguity has been considered by the implementor' is a more
useful criterion.

> The processing of X+A+B is complicated by the fact that
> A or B or both could be non-critical.  I suspect most
> implementations act as follows on receipt of X+A+B:
>   is X well formed? if not return protocolError.
>   is A recognized and appropriate (for X)?
>      If not and critical, return unavailableCriticalExtension
>      If not and non-critical, ignore A
>      Otherwise, is A well-formed?  If not return protocolError.
>   is B recognized and appropriate (for X or X+A, depending on above)
>      If not and critical, return unavailableCriticalExtension
>      If not and non-critical, ignore B
>      Otherwise, is B well-formed?  If not return protocolError.

Good point.  However, we'd get more predictable results (for someone who
does not known the particular implementation) if the implementation
ignores all non-critical controls which are incompatible with some other
control in the message.  Maybe implementations MAY ignore selected
non-critical controls that conflict with other controls, and SHOULD if
so ignore _all_ non-critical controls that conflict with some other
controls?  OTOH, we are talking about control combinations that either
fail or are unpredictable in any case, so maybe not...


One other detail: I don't think it fits the definition of protocolError
in section A.2 to return that for a control combination which MAY be
treated either as defined or undefined:

        protocolError (2)
           Indicates the server received data which has incorrect
           structure.

If servers are to return protocolError for such control combinations,
that must be added to the list of exceptions to the basic definition of
protocolError in A.2.

I already dislike the length of that list, though.  Maybe
unwillingToPerform or unavailableCriticalExtension is better.

-- 
Hallvard