adding my support...
[Allan] "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."
We (I) need OpenC2 today (not 6 mouths from now), the ecosystem in which it will most likely be used (TAXII2/STIX2/CybOX2 or MISP) is compatiable with JSON.
I wish to support this approach as well, to paraphrase, the mapping should have the "must" and these musts must be limited the the approved spec (if it not in the spec it is not a must)...
Interoperability is
in the "Must" of a specification, and not in the "Should"
and "Optional".
What about Should and Optional?
"Should"
- If there is a "best/suggested practices" then this realm of Should. While
the OpenC2 body should arbitrates "best/suggested" practices,
it should independent of the specification (and handle as they arise not before)
"Optional"
- again to use Allen's word: this is the realm of the "market" were flexibility can be encouraged
- Leave the Optional (and to a less extent, Should) to the implementers (coders) and the market to hash out. Let this back-and-forth inform the OpenC2 body next revision
From: <> on behalf of Allan Thomson <>
Sent: Sunday, October 15, 2017 3:58:33 PM
To: ;
Subject: Re: [openc2] Question about Sept meeting minutes
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
Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify
the sender and destroy and delete any copies you may have received.
