As posted on slack, cross-posting here.
Allan
On Oct 1, 2020, at 4:44 AM, Jason Keirstead <> wrote:
We've been made aware of something while trying to implement a feature using TAXII 2.1
Let's assume a TAXII GET request, has a primary data source, and a bunch of secondary data sources, and the end resulting STIX is supposed to be comprised of a merging of all of that data. Now assume one of the secondary data sources fails, but the primary and most of the other secondary sources succeed. In this scenario, there is no way to return the partially-complete STIX bundle, because the TAXII protocol (a) doesn't allow the 206 partial success response code anywhere, only 200, and (b) errors can only be communicated in the response body, not the envelope.
I would like to propose two things
- That all API GET requests add 206 as an allowed response code
- That error responses be moved into the envelope, not the body. This will allow you to return errors and STIX content when appropriate. We could also allow them in both (the body as well as the envelope) to support backwards-compatibility.
Thoughts?
-Jason KeirsteadDistinguished Engineer, CTO - IBM Security Threat Managementwww.ibm.com/securityCo-Chair - Open Cybersecurity Alliance, Project Governing Board
www.opencybersecurityalliance.org
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Attachment:
signature.asc
Description: Message signed with OpenPGP
