RE: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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)

-- 
Hallvard