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

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

At 08:38 PM 4/16/2004, Jim Sermersheim wrote:
>Actually, this is clear (see combination of controls in 4.1.11), but
>the current language says behavior is undefined.

I think the semantics are undefined, but we should define
how servers are to behave when faced with a combination
of recognized and appropriate controls whose semantics
haven't been defined.

Maybe protocolError is the best approach here.  However,
how about a client which specifies two controls of similar
function hoping the server supports one or the other
(and, if both, selects the "better" one).

Though I'm not necessarily convinced myself that this is
appropriate, how about something like:

  Clients SHOULD NOT be combined controls (with other controls
  of same or different types) unless the semantics of the
  combination have been defined (and known to it).  A server
  MUST NOT attempt to make use of a combination of controls
  whose semantics are not defined (or not known to it).  The
  server MAY ignore any non-critical control in the presented
  combination to reduce the combination to a sequence (including
  the empty sequence) which does have defined semantics.
  However, the server MUST NOT ignore any critical control
  in the presented combination.  If the combination cannot be
  reduced to a sequence which has a defined semantics, the
  server MUST return unavailableCriticalExtension.

  The semantics of control combinations, when defined, are
  generally found in the control specification most recently
  published.

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