Allan,
No. Much of any standard is informative text that provides background information or aids understanding. RFC 2119 says:
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:]
Sent: Tuesday, October 17, 2017 3:59 PM
To: Kemp, David P <>;
Subject: Re: [openc2] RE: [Non-DoD Source] RE: [openc2] Question about Sept meeting minutes
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: <> on behalf of "Kemp, David P" <>
Date: Tuesday, October 17, 2017 at 12:53 PM
To: "" <>
Subject: [openc2] RE: [Non-DoD Source] RE: [openc2] Question about Sept meeting minutes
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: [mailto:]
On Behalf Of
Sent: Sunday, October 15, 2017 11:58 PM
To:
Subject: [Non-DoD Source] RE: [openc2] Question about Sept meeting minutes
Works for me.
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: Re: [openc2] Question about Sept meeting minutes
From: Allan Thomson <>
Date: Sun, October 15, 2017 3:58 pm
To: "" <>,
"" <>
Duncan – I suggest that it is much simpler to just state that the
JSON mapping of the Language Specification is a normative specification for the JSON implementation of OpenC2.
There is no reason why the spec needs to state that other mappings are possible as the free-market allows that to occur whether you write it in a spec or not.
We are not precluding anyone implementing other mappings. But if you define OpenC2 in JSON then you *must* implement it according to the specification of that mapping.
Allan
From:
<> on behalf of "" <>
Date: Sunday, October 15, 2017 at 5:42 AM
To: "" <>
Subject: [openc2] Question about Sept meeting minutes
The meeting minutes for the Sept OpenC2 TC state "JSON, as an encoding, is non-normative". I'm not sure if we used that exact wording - but even we did, I'm not
sure it was correct. I believe current consensus is that JSON is mandatory as minimum implementation but we are allowing for other optional serializations in the future. I believe the point being made at the time was we were trying to say that if you did use
JSON, you had to do it the way specified. The reason for the 'if' was the optional serializations, not that JSON was 'non-normative'. I propose the following change:
Delete "Json, as an encoding, is non-normative. However,"
so it now reads:
"The property tables in the Language Specification are normative. If you elect to use Json, then it should be done in accordance with the json specified in the
Language Specification. The OpenC2 Language Specification permits the use of other encodings."
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
-------- Original Message --------
Subject: [openc2] Groups - OpenC2 TC Minut es 20 Sept 2017 uploaded
From: Joyce Fai<>
Date: Fri, October 13, 2017 4:43 am
To:
Submitter's message
Dear OpenC2 TC Members,
The minutes for the 20 September TC meeting is available for your review. We will vote to approve these minutes at our upcoming Wednesday, 18 October 2017 TC meeting (1100ET and 2100ET).
Looking forward to speaking to you then.
Best,
-- Ms. Joyce Fai
Document Name:
OpenC2 TC Minutes 20 Sept 2017
No description provided.
Download Latest Revision
Public Download Link
Submitter: Ms. Joyce Fai
Group: OASIS Open Command and Control (OpenC2) TC
Folder: Meeting Notes
Date submitted: 2017-10-13 01:42:40
--------------------------------------------------------------------- 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
--------------------------------------------------------------------- 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
