NOTE: The purpose of this ballot is to unify the TC and settle an issue that has been debated for months. This is a non-binding ballot that can be reversed at any time in the future by simple majority vote of the TC. This vote will run for two weeks to ensure adequate time given the upcoming Thanksgiving holiday in the United States. Please see Trey Darley's post for much more detail on how this in no way impacts our ability to pursue alternative serialization formats in the future (XML, protobufs, JSON-LD, OWL, etc.)
https://www.oasis-open.org/apps/org/workgroup/cti/email/archives/201511/msg00105.html
Elaboration:
============
By adopting an MTI representation, we are explicitly requiring any vendor or software product claiming CTI-compatibility to minimally support the JSON serialization. Vendors are free to define and support additional serializations (XML, protobufs, etc.) to address their specific use cases, but if they do not support the MTI serialization, their products are not CTI-interoperable and they cannot claim to support the CTI standards.
The committee chairs recognize the need for additional optional serialization formats, either now or in the future. The committee chairs are prepared to support standardizing alternative serialization formats for interoperability purposes in collaboration with the interested parties but until the TC has approved the STIX 2.0, TAXII 3.0 and CybOX 3.0 specifications we as a community do not have the bandwidth to support this effort.
Regardless of what alternative serialization formats may be defined and standardized in the future, the JSON MTI will remain the "must be this tall to ride" in terms of CTI standards compliance. |
