[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] RE: [Non-DoD Source] RE: [openc2] Question about Sept meeting minutes
Dave – Other specifications have both informative and normative statements. But in general its clear what is normative and what is informative by the strict use of the terms such as MUST, MAY, SHOULD….etc.
My point was whether there are normative statements outside of the property tables in the language specification.
Typically, there are and that was why I suggesting why there is a need to state solely that the property tables are normative.
OASIS has rules for this. I’m not sure why we are even necessarily needing to discuss.
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions).
So wherever the Language Specification includes 2119 keywords, that is a normative requirement for which a conformance test can be devised. There is no conformance test for:
The OpenC2 Language Specification defines the set of components to
assemble a complete command and control message capability and
provide a framework so that the language can be extended to accommodate
new technologies. To achieve this purpose, the scope of this specification includes:
so the Purpose and Scope section of the language spec is non-normative. If there is not currently a requirement in the LS that says implementations MUST serialize commands in accordance with the property tables, then that requirement must be added to the LS, it would be normative, and implementations can be tested against that requirement. If there is no normative requirement regarding property tables, then they are only informative. I don’t see such a requirement, the closest I could find is:
Table 2-1 summarizes the fields and subfields of an OpenC2 Command.
OpenC2 Commands MUST contain an ACTION and TARGET and MAY contain
an ACTUATOR and/or COMMAND-OPTIONS.
That is both excessive and insufficient as a requirement – excessive because the property table for a command specifies which fields are required, and insufficient because the content of the property tables can be ignored.
Dave – isn’t the entire language specification normative?
That is, wherever the language specification states MUST, SHOULD, MAY….etc then that is a normative definition. That is not restricted to only property tables but all normative statements included in the language specification.
I agree completely with your wording: “The JSON mapping of the Language Specification is a normative specification for the JSON implementation of OpenC2.”
That supplements but does not replace the existing: “The property tables in the Language Specification are normative.” That means that an implementation of any other serialization (such as XML or Protobuf) of the Language Specification must also conform to the property tables, because the property tables apply equally to all serializations.
Works for me.
sFractal Consulting LLC
iPhone, iTypo, iApologize
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php