Add TAXII Envelope / Bundle to the TAXII specification

[jordan2175]

We had a call last week and then talked about it again today at the F2F. The idea is that we should define a bundle or envelope in TAXII so that all media types for TAXII endpoints, are TAXII media types.

If we do this, we will need to add either a URL parameter or x-header to allow the client to specify which versions of STIX content it can support. This means, we will also need to define what it means if the parameter is not populated or is populated with a certain value. We should also support the "all" keyword as well.

[varnerac]

If TAXII adds its own envelope, it shouldn't be a bundle. It's too confusing to have a STIX and TAXII object with the same name.

Additionally, the envelope will likely need to handle some TAXII accounting that we used to execute through HTTP constructs. While returning an HTTP 206, "Partial Content", response seems attractive, RFC 7233 restricts it to Content-Range headers, which we aren't using:

If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a payload consisting of the range.

So I think the envelope will need fields like:

name	type	desc
bundle	STIX Bundle	A STIX bundle of results
more	boolean	default false more content available at time of request but not returned

I don't think we need an exceeds_max field for cases where the client requests 100 items but the server returns a max of 50. In that case, we have the number of items back and whether or not there are more.

• If I request 100 and get a 50 item bundle and more=true in the envelope, I can infer the server limit is 50
• If I request 100, the server limit is 50 but there are 30 items, the server just returns them. Who cares that the client limit and server limit don't jibe?
• If the client limit is under the server limit, no problems

[jordan2175]

I was kind of thinking of a more simple object. A TAXII wrapper that has say 2 properties:

1. objects - A list of STIX Objects
2. more - A boolean like you have said.

[varnerac]

I hate to throw away the STIX Bundle object since it’s the idiomatic way to package STIX Objects. Additionally, implementors likely have code bases that validate bundles. This makes it easy to reuse that code.

[jordan2175]

We have added this to the spec for working draft 04, we still need to address the "more" issue in regards to pagination. But that will be done in a separate issue.