[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. Allan From: <openc2@lists.oasis-open.org> on behalf of "Kemp, David P" <dpkemp@radium.ncsc.mil> Allan,
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 From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
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. Allan From: <openc2@lists.oasis-open.org> on behalf of "Kemp, David P" <dpkemp@radium.ncsc.mil> Allan, 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. Dave From: openc2@lists.oasis-open.org [mailto:openc2@lists.oasis-open.org]
On Behalf Of duncan@sfractal.com Works for me. Duncan Sparrell 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]