[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Protocol: control specifications.

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.


At 01:37 PM 3/8/2004, Hallvard B Furuseth wrote:
>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 <h.b.furuseth@usit.uio.no> 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)