[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2] Question about Sept meeting minutes
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: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Sunday, October 15, 2017 3:58:33 PM To: duncan@sfractal.com; openc2@lists.oasis-open.org 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: <openc2@lists.oasis-open.org> on behalf of "duncan@sfractal.com" <duncan@sfractal.com> 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
--------------------------------------------------------------------- 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]