All,
Lately I have found myself describing requirements for TAXII 1.0 and TAXII 1.1, and I have realized that these are not really captured anywhere. This issue is an attempt to better document the requirements. Please feel free to request additional information on certain topics.
The requirements are in no particular order, and are numbered for referencing.
01 - Protocol Agnostic, Message Format Agnostic
TAXII was designed to be agnostic in terms of protocol (e.g., HTTP) and message format (e.g., XML). This was because we anticipated that people would want to create and use their own protocol/message bindings. This is why there is a TAXII Services Specification and HTTP/XML Bindings. This also resulted in, for instance, X-TAXII-Protocol being defined.
02 - Digital Signatures
In certain contexts, being able to verify the authenticity of a TAXII Message is important. For this reason, all TAXII Messages contain an XML Digital Signature field. This caused all TAXII Messages to have data, and therefore required HTTP Posts for all TAXII Message exchanges.
03 - Architectural Flexibility (Push/Pull)
Allowing a producer or consumer to be a network Client or network Server allows the design of a TAXII Solution to be more flexible. For this reason, both pushing (producer is a client) and pulling (producer is a server) were designed into TAXII.
All,
Lately I have found myself describing requirements for TAXII 1.0 and TAXII 1.1, and I have realized that these are not really captured anywhere. This issue is an attempt to better document the requirements. Please feel free to request additional information on certain topics.
The requirements are in no particular order, and are numbered for referencing.
01 - Protocol Agnostic, Message Format Agnostic
TAXII was designed to be agnostic in terms of protocol (e.g., HTTP) and message format (e.g., XML). This was because we anticipated that people would want to create and use their own protocol/message bindings. This is why there is a TAXII Services Specification and HTTP/XML Bindings. This also resulted in, for instance,
X-TAXII-Protocolbeing defined.02 - Digital Signatures
In certain contexts, being able to verify the authenticity of a TAXII Message is important. For this reason, all TAXII Messages contain an XML Digital Signature field. This caused all TAXII Messages to have data, and therefore required HTTP Posts for all TAXII Message exchanges.
03 - Architectural Flexibility (Push/Pull)
Allowing a producer or consumer to be a network Client or network Server allows the design of a TAXII Solution to be more flexible. For this reason, both pushing (producer is a client) and pulling (producer is a server) were designed into TAXII.