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

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 21:38:02 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 4/16/04 3:45:57 PM >>>
<snip>
>>However, also consider
>>what to do if the same control appears twice,
>
>For most controls, that's a protocol error. Unless the control
>specification says the control can appear multiple times, it cannot.
>This should be made clear in [Protocol].

Actually, this is clear (see combination of controls in 4.1.11), but
the current language says behavior is undefined.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 17 Apr 2004 00:14:41 -0700

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