RfcKeywords
IETF RFC 2119 defines conformance keywords (MUST, SHOULD, ...), that are often used in specifications. There is an open debate on the scope of application of these keywords; is it OK to make requirements on things that cannot be called agents (e.g. a spec) using these keywords? If not, is there a need for a different set of conformance keywords for this kind of things, but still denoting the level of the requirement?
To summarize, this page argues that:
- it is good both in the spirit of the RFC and for a quality of a spec to use RFC Keywords to describe behavior of agents
- RFC Keywords are better used with well-defined conformance objects (aka classes of products)
- using RFC Keywords to describe semantics has some use cases (e.g. different level of requirement)
Detailed discussion follows.
DanConnolly (and others) defends that MUST is for agents, encouraging "to use the word MUST to constrain agents in processes, not to just make declarative statements". @@@ This document denotes other usages as a "misuse", but is this with regard to what the RFC says or with regard to the intended result?
The QA WG (and others) thinks that using them to define conformance requirements in specificiations is good, since it allows:
- to clearly identify conformance requirements in a text
- to denote the level of requirement bound to the said requirement
The RFC itself imposes that these keywords "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm", and not "to try to impose a particular method on implementors where the method is not required for interoperability" ; I [[[DomHazael]]] am starting to find an answer in this conformance requirement even though the MUST it uses is applied to non-agents (the RFC keywords).
Agents vs Conformance objects?
My [[[DomHazael]]] understanding of the gap is that specifications authors should use RFC Keywords only applied to (what the QA WG calls) classes of products, that is to objects that are supposed to conform with the specification (see also Conformance Terms), and to denote a specific level of conformance (required, suggested, optional); in consequence, one should not say "X MUST be Y" (grammatical form: passive), but "X MUST do Y" [X being a particular conformance object] (grammatical form: active). This distinction active/passive matches what I understand behind the "agents" concept.
After further thoughts, I think there are 2 aspects; to use RFC Keywords in the spirit they have been designed - for interoperation, they have to be used :
- for conformance objects
- for operation
Thus, a conformance object capable of an operation is what I understand as being called as an agent in MUST is for agents; I think it also raises a flag that a given conformance object should be associated with a list of operations it can handle, and then a "good" (well-formed?) conformance requirement using RFC 2119 Keywords would be Conformance_object X MUST Conformance_operation in such and such conditions. Now that I understand it that way, I think it's fair assessing that MUST is for agents in the RFC spirit, although I remain to be convinced that there is harm done when extending their usage to a broader sense.
Imperative/Prescriptive vs Declarative
Then there is a question whether it's more appropriate to use an imperative style "a conformant implementation MUST do this" or a declarative style "a conformant implementation do this". The former allows quick identification of the conformance requirement, but is harder to read than the latter. Although I don't see how to denote a weaker requirement level (suggested or optional) without using should/may.
Does a Spec needs a conformance model?
Finally, there is a related question of whether one needs to define a conformance model in order to create a specification (see e.g.a thread on www-qa-wg in January 2004 for the RDF This is definitely bound to the question of defining MeaningVsBehavior.
