I see where you're going now.
No, my problem and solution don't attempt to change the semantics of the criticality.
I saw a statement made by John McMeeking which said "... I'd sure hate to find out that the extension had been ignored."
From that, I assumed that there are use cases where the client wishes to send a control marked non-critical, yet also wishes to know if the control was applied.
So, I was suggesting that good control specifications can be written such that there is either: a) always a response control, or b) a field in the request control that causes a response control to be returned. This allows the client to know whether the control was applied (the absence of a response control indicates that the control was ignored). This does not alter the semantics of the criticality field.
You're right, this is not germane to the current discussion. I just wanted to note it because I didn't want that aspect of John's statement to be seen as another requirement for causing the server to enforce correct criticality.
>>> Hallvard B Furuseth <firstname.lastname@example.org> 3/8/04 2:37:09 PM >>>
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 < email@example.com > 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