Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
TAXII 1.1 1.0 Pain Points
- No automatic initial endpoint discovery (if client doesn't know Discovery Service URL, he has no predefined way of finding it out). Related: #58
- AKA - No network-level discovery
- No protocol version negotiation support. Related: #70
- Too much optionality
- Lack of single architecture - TAXII was designed to support multiple architectures
- No defined authentication
- Authentication is the key to the "circles of trust" that TAXII promises and required for the underlining trust model sharing information is built on - and such should probably be more than just "do something"
- Without Authentication you can't do things like only return a subset of services in a discovery response based on what the authenticated user has access to (IE admin can see all but jsmith can only see these 3 services)
- Unnecessary network traffic
- Messages are too big
- It is impossible for a client to limit response size in any way (related: #17):
- No offset/limit support
- COUNT_ONLY support is optional
- No first timestamp/last timestamp information per Collection
- Calendar & Wall-clock time are the only (and poor) means of data request/partitioning
- Server's game of "Guess what I'm thinking."
- XML-in-XML: Envelope and Content are not separate or easily severable:
- Content's attributes for xmlns & schema may float to ancestor nodes in the Envelope and still be valid
- Malformed Content can break a message, often leading to
- At-Runtime/Per-Request XML validation can be a heavy burden depending on architecture
Collection management service
- Collection Volume value is so vague that almost not usable - it is not required to be exact rate per day (why day?) or a number of content blocks in a collection, just "the typical number of records added to this Data Collection daily".
Clone this wiki locally
Press h to open a hovercard with more details.