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?
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 discussionWhat 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 AMTo: Allan ThomsonCc: cti-stix@lists.oasis-open.orgSubject: 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 0050On 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 SolutionsThis 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 AMTo: cti-stix@lists.oasis-open.orgSubject: [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
|