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

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 05 May 2004 21:55:10 -0600

I would rather not introduce the ability to overload the criticality
field in this way. I'd rather keep it simple 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.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 4/17/04 1:14:41 AM >>>
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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 May 2004 21:44:13 -0700

At 08:55 PM 5/5/2004, Jim Sermersheim wrote:
>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: 

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 7 May 2004 15:02:01 +0200

> not to return an error (as opposed to suggesting which code to

I thought that was the intent, which looked reasonable to me.

>   request as a protocol error.

Sounds too strict to me.  Or at least, it can be interpreted too strict.
For example, does that forbid the combination of the rfc2649 Operation
Signature control with e.g. the rfc2891 Server Side Sorting control?
Neither document explicitly states how the combination should work, but
rfc2649 does say how to apply that control to LDAPMessages in general,
and the combination seems to make sense to me.

Also, I wonder about the combination of controls defined in different
"standards repositories" or whatever one should call it.  If all
controls were RFCs, one control spec could list all previously defined
controls.  However, in the previous discussions of controls, people were
referring to controls that I could not find RFCs for.

Finally, one detail: If we stick to RFC controls, each control author
will need to check all previous RFC controls.  It might be easy to miss
one, and make a control combination with an obvious semantics invalid.
We could fix that with a requirement that all LDAP control RFCs must
have the phrase "LDAP control" in its title.  Or someone (IANA?)  could
maintain an official list of published controls.  However, it seems
simpler to me to allow controls that obviously do not interfere with
each other, to be combined even if their specs do not say so.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 7 May 2004 17:21:06 +0200

I wrote:
>>   combination have been defined.  (...)
> 
> Sounds too strict to me.  (...)
> 

Also, this requirement breaks requests that combine the ManageDsaIT
control (rfc3296) with previously defined controls (e.g. paged results -
rfc2696), since rfc3296 does not say how to combine ManageDsaIT with
other controls.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 May 2004 08:24:44 -0700

There is a subtle difference in the suggested text from the
current text that might be, well, a bit too subtle.

The current text talks about avoiding combinations whose
semantics are not SPECFIED while the suggested talks about
avoiding combinations which are not DEFINED.  While defined
and specified are synonyms of each other, the latter can
be viewed as implying there is a specification (e.g., document)
where the semantics are defined, the former only can be viewed
only as implying the semantics are defined (without regard
to where they are specified).

In the example of Sort+SignedOp, I think it can be argued that
the semantics are defined even though they are not explicitly
specified.  The intent of the text is not to prohibit such
combinations.

The text is intended to disallow use of combinations where the
semantics are undefined, such as a combination of PagedResults
[RFC2696] and VLV [draft-ietf-ldapext-ldapv3-vlv-08.txt].

If I reading everyone's comment well, I think we have consensus
on what we want to say but just haven't found the words that say
it well enough.  Specific suggestions welcomed.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 May 2004 16:43:12 +0200

> and for requests which don't have responses.)

If we keep the MUST, I disagree with a MUST for the client.
Clients should be free to trust the server to produce correct
data, except when security dictates otherwise.

-- 
Hallvard