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

RE: Protocol: control specifications.

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