|
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 12/29/03 12:40:56 PM >>>
>Kurt D. Zeilenga writes: > >> I do not see particular useful to detail how the server is to >> behave when a client violates a particular absolute requirement >> (or prohibition) of the controls (or other) specification. >> Certainly, a violation of an absolute requirement/prohibition >> is a protocol violation. Whether or not server chooses to >> return protocolViolation or just ignore it (be liberal in what >> you accept) or do something else can be left an implementation >> detail. > >After thinking a bit more about this, I believe [Protocol] should >require protocolViolation if the required criticality of a supported >control is violated. That will teach programmers who use a server >which does support the control, to write programs which will work >right when moving to a server which does not support the control. > >For example, the No-Op control, which prevents the effects of update >operations, has criticality TRUE. It would be rather unfortunate to >run a program which uses it with criticality FALSE against a server >which does not support the control. I would rather take the less limiting approach, and place this kind of imperative in the control specification(s).
Jim |