[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Re: [EXT] [cti] Embedded Relationships
From the very beginning (back in 2012), our philosophy has been that TAXII is one of the ways we envision that STIX content is shared. What I mean is that while I think we all agree on the value of a standard like TAXII to meet the foundational needs of the community, TAXII doesn’t need to try to address every possible use case for transporting STIX content. Therefore, as a TC we could decide that support for some advanced message queue capabilities are beyond the scope of TAXII. We also could decide that they are in scope. This is one of the key questions we need to decide with respect to channels…
Yes, as you remember we had a long debate about these back when TAXII first started. My personal preference was and remains ZeroMQ. But that is just me.
The primary reason we as a TC decided against using these was two fold:
1) Vendors that either do this today or produce/consume the content that we need today, all use RESTful HTTP designs. Doing something different here would slow adoption.
2) We did not want to prevent TAXII adoption in the Enterprise due to firewall rules that might need to be added for messaging protocol XYZ.
I am sure this debate will come up again once we start work on 2.1 and finish TAXII channels. The way I see it, there are two real options for channels:
a) reopen debate on message protocols
b) define something like HTTP long-polling (this is where the TC had landed on it the past.)
From: Jerome Athias <email@example.com>
ZeroMQ, AMQP, et al are clearly better architectural fits for messaging. However, ZeroMQ is not a standard, it’s a library; AMQP has a de-facto meaning of “pre-1.0 AMQP”, which in my experience is predominantly RabbitMQ.
JA> Just adding a reference to a (OASIS) Standard (received 2016 Open Standards Cup) for the record
Description: S/MIME cryptographic signature