STIX Sightings

Copying cti-taxii on the reply.  The current state of the TAXII 2 conversation is that essentially this: * There will be a channel-based API for broadcasting messages * There will be TAXII messages and workflows, but we haven’t defined any yet * There are certain cases (e.g., get by ID) that seem to fit much better into a straight-up request/response API vs. the channel-based concept  The TAXII SC is currently working through what the difference really is between the Channel API and the Query API, and what that means for the TAXII SC (really, CTI TC) work products - do we need both types of API? If so, do they belong in different specs?  I personally think that some form of a "STIX Repository API" is worth considering. I call it that because the URL structure would be intrinsically linked to STIX (e.g., GET /indicators/<indicator-id>/ ). I personally don't care which SC the work is done in, as long as we are doing valuable work that makes sense and advances STIX/TAXII. The notion of a "STIX Repo API" probably sits right on the STIX/TAXII scope boundary for most people.
> The tl;dr is to add an optional 'broadcast' parameter to TAXII query.
> If not specified, assume that a query is targeting just the local CTI
> repository. If the flag is specified, the CTI repository receiving the
> query acts as a proxy, forwarding the incoming query to all the hosts
> implied by the specified trustgroup(s), collecting the query results,
> and passing them back to the client.  Alternatively (and I'm not sure how well this would actually work, I'm just putting it out there for discussion), if you had a STIX Repo API and a TAXII Channel API, the client would know whether the request was "direct" or "broadcast" based on which URL it was asking.  **I think they key consideration here is whether a TAXII Server is a repository, a message broker, or both** - partly, this is what's under discussion in the TAXII SC. TAXII 1.x sort-of folded both concepts into the same spec. The TAXII 2 conversations started out by focusing on the message broker aspect and found that certain repository functions (e.g., get by ID) are somewhat awkward to implement over a broker (e.g., you need to broadcast a request and hope that a broker client is subscribed, and you need to be able to handle 0-* responses to your request). This has led to the recent discussion on Query API that Trey mentioned.  Thank you. -Mark