Personally, I am not prepared to vote for any binding, be it JSON, XML, JSON-LD, CSV, etc… until we see all of the requirements (use cases) we are trying to satisfy.
That is like trying to select your software stack before you know what you are trying to build. What if a use-case comes up that whatever binding we choose won’t satisfy (or satisfy easily)? Then do we go back and take a mulligan?
From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org]
On Behalf Of Foley, Alexander - GIS
Sent: Tuesday, October 06, 2015 2:05 PM
To: cti-users@lists.oasis-open.org; cti-stix@lists.oasis-open.org
Subject: [cti-users] Model / Binding Motions
By my count:
1.
We have Bret’s motion that we require a default binding for STIX and CybOX and it requires a second.
a.
If this motion succeeds, we have Bret’s motion that JSON be chosen as the default binding for STIX and CybOX and it requires a second.
i. Kevin Wetzel, I apologize but I do not see you as a member of the cti committee…
please follow up with myself, Rich, Chet or OASIS if that’s an incorrect assumption
b.
We also have an (alternate?) proposal from Cory that JSON-LD specifically be chosen as our default binding and it requires a second.
I must admit this conversation has been very difficult to follow – if I’m missing a key motion that we construct a UML / RDF / OWL model that’s separate
from choosing a new preferred binding / data encoding, please feel free to propose or second any motions.
Sounds good...
I would like to formally make a motion that we require a default binding for STIX 2.0 and CybOX 3.0.
If this is agreed upon, then:
I would like to formally make a motion that the default binding for STIX 2.0 and CybOX 3.0 be JSON.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Bret, I think we need to propose that STIX, CybOX, and TAXII have to require a default binding type first. Then the MTI motion could be changed to something like, “I would
like to propose that we adopt JSON as the default binding”.
We have had a good discussion here and on the wiki and I have seen a lot of people advocating for JSON to be used as the MTI. While a few other options have been tossed around
and discussed they do not seem to have an advocate pushing for them nor do they seem to have the broad support that JSON does.
Therefore, I would like to formally propose that we adopt JSON as the MTI for STIX 2.0 and CybOX 3.0.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:
1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of
discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?
Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion
makes it clear that we are considering it
2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size
and complexity. What examples would be sufficient?
3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product
and I want to add STIX support, won’t developers have to write code?
I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how
that actually works (the more concrete the example the better, at least for me).
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
|