Re: [cti-stix] CybOX Versions in STIX?

[Paul Patrick <ppatrick@isightpartners.com>]

Ivan,

Actually I could see CybOX evolving faster than STIX due to the fact that CybOX has more potential consumers (MAEC, DFAX, OpenC2) that would drive faster evolution than STIX. If we follow the rules for evolution that minor revisions MUST backwards compatible with previous versions and any incompatible change requires a major release, why wouldn't we need the spec_version and that the dependency from STIX would be to a specific major version and a base minor version from which later minor versions could be used?

Sent from my iPhone

On May 10, 2016, at 3:07 PM, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

At this point I think the assumption has been that a particular version of STIX would support a particular version of CybOX, and only this version.

E.g.,

• STIX 2.0 would support CybOX 3.0
• STIX 2.1 would support CybOX 3.1
• Etc.

Does this align with the existing community perceptions? Are there any particular needs or cases where STIX would want to support multiple versions of CybOX at one time? The only hypothetical example I can come up with is if STIX incorporates data from another source, such as MAEC, that uses a different version of CybOX. However, I would imagine that, for compatibility reasons, STIX would only want to incorporate data sources that use the same version of CybOX that it uses.

This came about from some recent discussions in CybOX about the spec_version field and whether we need to incorporate it in the CybOX Container/ArgleBargle. If the assumption is that STIX, MAEC, and other CybOX users will only support a particular version of CybOX for any one release, then perhaps this field isn’t needed.

Regards,

Ivan