OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: TAXII 2.1 Partial Response Error Handling

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.

Jason Keirstead
Distinguished Engineer, CTO - IBM Security Threat Management

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]