Subject: RE: Protocol: control specifications.

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Mar 2004 22:37:09 +0100

Jim Sermersheim writes:
> I'm guessing that you mis-read my statement because I can't see how the
> semantics statement affect the problem I mention.

The criticality field is just supposed to say whether or not to perform
the operation.  If the criticality field causes the addition of a return
control, then that violates the semantics statement.

If you meant that a return control should be added independently of the
criticality field, you are right, that has nothing to do with additional
semantics to the criticality field.  But I don't see what that has to do
with the discussion.  Unless you you referred to my message
  http://www.OpenLDAP.org/lists/ietf-ldapbis/200401/msg00083.html
which reported that rfc2649 and rfc2891 do say that criticality TRUE
causes the addition of a return control.  If so, yes I quite agree they
should not have done that.

>>>> Hallvard B Furuseth <[email-masked]> 3/8/04 11:51:13 AM
>Jim Sermersheim writes:
>> - If there are cases where clients have a need to set the criticality
>> to false, and also be notified whether the control was applied, then
>> the control specification ought to provide some return control for
>> purposes of acknowledgment.
> 
> ...if the control was applied. True, but that's another issue.
> I think it's covered by this text in the draft:
> 
>   (note: the semantics of the criticality field 
>    are defined above should not be altered by the control's 
>   specification)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Mar 2004 14:29:50 -0800

I note that we had a number of discussions in LDAPEXT regarding
flaws in RFC 2649 and RFC 2891 (and a number of other control
specifications) criticality handling, mostly dealing with
overloading of criticality semantics but also dealing with
criticality of response controls.

In general, I believe the consensus (at that time) was:
        a) control specifications should not make server
        processing of an operation extended by a control
        dependent on the criticality of that control, and
        b) criticality of a response control is not generally
       relevant to client processing of an operation extended
        by a control.

I think consensus today is much the same.  [Protocol] appears
to reflect this.

Kurt