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…
My $0.02…
Rich
From: [mailto:] On Behalf Of Bret Jordan
Sent: Sunday, May 07, 2017 11:10 AM
To: Mark Davidson; Jerome Athias
Cc: Jason Keirstead; Reller, Nathan S.; Terry MacDonald; Allan Thomson; Struse, Richard; John-Mark Gurney;
Subject: Re: [cti] Re: [EXT] [cti] Embedded Relationships
Jerome,
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.)
Bret
From: Jerome Athias <>
Sent: Sunday, May 7, 2017 12:18 AM
To: Mark Davidson
Cc: Jason Keirstead; Reller, Nathan S.; Terry MacDonald; Allan Thomson; Bret Jordan; Struse, Richard; John-Mark Gurney;
Subject: Re: [cti] Re: [EXT] [cti] Embedded Relationships
<snip>
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
http://mqtt.org/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
