-
Notifications
You must be signed in to change notification settings - Fork 21
Proposal: Packages Cannot Contain Other Packages
- Status: Accepted
- Closed: March 23, 2015
- Issue: #223
Per previous conversations on the mailing list and in-person calls, the FS-ISAC Report Object Proposal has been accepted for version 1.2 of STIX. In order to present the big picture of whether or not to include the report construct at all certain decisions had to be made but the specifics of those decisions were not discussed by the community.
This proposal presents in detail the decision to prohibit packages from containing other packages. The other report object proposals are:
The current report object proposal suggests that the ability for STIX_Package constructs to contain other STIX_Package constructs should be deprecated. The rationale for this is that because STIX_Package is only a wrapper it does not make sense semantically to have one raw wrapper embedded within another. Why not just include the content of the inner wrapper in the outer wrapper?
However, the effect of this is that content re-distributors or distributed query engines that query multiple sources and collect them into a single response will need to process the content that they're consuming. While previously they would be able to embed the responses they got into one big STIX_Package with this change they'll be forced to collapse those responses into a single STIX_Package. If the STIX_Package is just content that's easy, however markings, information source, profiles, and potentially digital signatures would need to be re-written in order to perform this consolidation. That hardship on content redistributors and distributed query engines can be prevented by maintaining the ability for packages to be conveyed in other packages.
Note that this does not mean that STIX_Package is expanding its role to become more than an envelope. It simply means that in some cases you might have several smaller envelopes in one larger envelope.
It also does not mean that the ability to reference between STIX_Package constructs by @idref would be permitted. That use case was specific to allowing versioning and related context and so still goes away. The embed, capability, however, could remain to enable this use case.
Decision Point: Should STIX_Package constructs be allowed to contain other STIX_Package constructs, or should that capability be removed (as proposed)?
Feedback can be sent to the public STIX discussion list (make sure to join first), as a public comment on the github issue for the report object or sent privately to the core STIX team at stix@mitre.org.