|
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.
Jim
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 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 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 |