TAXII 1.1 1.0 Pain Points

jordan2175 edited this page Aug 18, 2015 · 11 revisions


  • 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
  • XML

Poll Service

  • 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".