[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: [EXT] Re: Bundle add Spec_version
It seems like the easiest and simplest long-term solution that ensures the most interoperability is for every object to just include the spec_version that is complies with. This prevents guessing and interpretation. It also ensures that things are done right. The moment we do things like inherited versions under certain conditions, someone is going to get it wrong in code.
Bret From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Friday, September 21, 2018 10:14:24 AM To: drew.varner@ninefx.com Cc: Bret Jordan; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: [EXT] Re: Bundle add Spec_version Are you talking about a 2.1 bundle with 2.0 objects inside it?
Yes, that would not work with this approach. - Jason Keirstead Lead Architect - IBM.Security www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From: drew.varner@ninefx.com To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc: cti-stix@lists.oasis-open.org, Bret Jordan <bret_jordan@symantec.com> Date: 09/21/2018 12:37 PM Subject: Re: [cti-stix] Re: [EXT] Re: Bundle add Spec_version Sent by: <cti-stix@lists.oasis-open.org> Wouldn’t this create ambiguity for 2.0 objects, where the absence of version indicates 2.0? How would you determine if an object is 2.0 or inherits from the bundle? On Sep 21, 2018, at 11:32 AM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote: I would like to expand on this idea a little bit, because I think there is a wider opportunity here to improve something we did in CSD01. - This property on a bundle, previously indicated the version of the bundle as well as all of the objects inside it. - The reason we removed this property from the bundle, was because we added spec_version to each SDO/SRO, and made it a mandatory property - However, this makes it ambiguous as to what the version is, of the bundle object itself - hence this discussion What if we revisit this change we made - and do this instead - We keep spec_version on the bundle as the previous definition - it defines the version of the bundle itself, as well as objects within - We make spec_version an *optional* field on every SDO/SRO. If it is *not* present, then the SDO/SRO inherits the value from it's bundle. - Jason Keirstead Lead Architect - IBM.Security www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown __________________ Your faith in spec reading is admirable :-) Allan Thomson. CTO, lookingglass cyber solutions. Www.lookingglasscyber.com. This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited. From: Bret Jordan <Bret_Jordan@symantec.com> Sent: Wednesday, September 19, 2018 9:12:52 AM To: Allan Thomson Cc: cti-stix@lists.oasis-open.org Subject: Re: [EXT] Re: Bundle add Spec_version We could do that or just be super clear in the description, something with a MUST statement so that it is flagged when people parse and extract things from the document. Bret Sent from my Commodore 64 PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 On Sep 18, 2018, at 6:27 PM, Allan Thomson <athomson@lookingglasscyber.com> wrote: Suggest to make it clear that is not the contained object versions then we should call the property something else. Ideas: - bundle_spec_version - bundle_spec - bundle_wrapper_spec Allan Thomson, CTO, Lookingglass Cyber Solutions This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited. From: cti-stix@lists.oasis-open.org<cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Sent: Tuesday, September 18, 2018 11:41 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Bundle add Spec_version All, I would like to start a thread here to discuss adding back the spec_version property to the bundle in STIX. A little bit of history: 1) We had spec_version on the Bundle in 2.0. However, we had problems with it, as it was unclear if it meant the spec version of the objects in the bundle or the bundle wrapper itself. 2) Based on this, in 2.1 we added spec_version to every object and removed it from the bundle. I am thinking that we may need to add it back to the bundle with a clear definition that it is the spec version of the bundle wrapper itself. Thoughts? Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]