RE: Clarifying Channel-Based TAXII (was TAXII 1.5)

Changed subject to not take away from the discussion of your proposal, which is now listed on the TAXII 2 landing page [1].  I'll do my best to answer those questions:
> Are there separate parts in that idea that can be evolved separately? Yes, absolutely. The idea is that the channel concept and the ways to access channels (i.e., the protocol) would be defined in TAXII 2.0. What channels exist and what messages are permitted on them would evolve separately. The idea would be to nail down a small set of channels for TAXII 2.0, and then add channels as necessary in TAXII 2.x releases. The idea would be to not touch the channel concept or underlying protocol after TAXII 2.0. Note: I've added this information to the Channel-Based Concept overview.
> are there different discussions about the components? Not yet, though that needs to happen in order to make progress. My hope would be to have a "rough consensus" design on Channels and ways to access channels, and focus the discussion on "which channels and for what purposes".
> what are the must-haves and nice-to-haves in the proposal? I don't have a good answer for this right now, but it's a good question!
> is there a low level protocol definition (like the one I tried to describe in my mail)? Not yet. The idea would be to use an existing protocol (like one of the ones listed here [2]). We've put together some requirements on the requirements page [3]. I see TAXII 1.x as not being "native" HTTP (because of all the X-Headers and such), to the detriment of TAXII 1.x. Ideally, whatever protocol we'd pick, we'd have be as close to the bare protocol as possible.  Thank you. -Mark [1]  http://taxiiproject.github.io/taxii2/  [2]  https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Formats-and-Protocols  [3]  https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Requirements#protocol-requirements