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

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

At 08:55 PM 5/5/2004, Jim Sermersheim wrote:
>I would rather not introduce the ability to overload the criticality
>field in this ways.

It does kind of sound like a new feature...

>I'd rather keep it simple

That's generally wise.

>by stating that the: 
>"server MUST NOT make use of a combination of controls whose semantics
>are not defined (or not known to it). When such a combination of
>controls is encountered, it is RECOMMENDED that the server return
>protocolError. Otherwise behavior is undefined.

I dislike the wording as it could be taken as allowing the server
not to return an error (as opposed to suggesting which code to
return in this case). 

How about?
  Controls are not to be combined (with other controls
  of same or different types) unless the semantics of the
  combination have been defined.  When an implementation
  (client or server) encounters a combination of controls
  whose semantics are not defined (or not known to that
  implementation), the implementation MUST treat the
  request as a protocol error.

(Note: I generalized this for both clients and servers,
and for requests which don't have responses.)


>Comments?
>
>>>>but containing different
>>>>parameters, and the control is implemented by setting a variable
>for
>>the
>>>>operation to that parameter. With the current text, the server is
>>>>required to always pick e.g. the parameter with lowest value,
>instead
>>of
>>>>just using the parameter in the last control. Or it could detect
>the
>>>>situation and return unwillingToPerform, but then it will still
>need
>>>>extra state info in order to notice the situation.
>>>
>>>I am curious as what current implementations do when presented
>>>with multiple controls of the same type within a single PDU.
>>>OpenLDAP, IIRC, treats this as an error condition.
>>
>>I think treating as an error is the best policy. This is really no
>>different than combining two different controls. If the spec doesn't
>say
>>what should happen, then behavior is undefined.
>>
>>We currently recommend that clients not do this. I propose
>recommending
>>that servers return an error, but allowing them to handle these cases
>in
>>an undefined way.
>>
>>If we do recommend it, we need to recommend an error code. I prefer
>>protocolError, but it's documented as having a very specific meaning
>>followed by a growing list of exceptions (this would add to that). A
>>second choice is unwillingToPerform.
>>
>>Jim