|
I agree, and suggest that once we have a stable control guidelines document, that we revise the existing control specifications to bring them inline (though I'm not implicitly volunteering to do the work).
JIm
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/8/04 3:29:50 PM >>> 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. Kurt 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) > >-- >Hallvard |