[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
I wonât, that day is bad for me unfortunately (training all next week). Maybe a 30 minute slot on Friday? From: Bret Jordan <Bret_Jordan@symantec.com> Matt, et al., Do you have time next week after the normal TC working call to talk through this? Or I can also do Thursday the 20th at 4:00 ET / 2:00 MT? Let me know and I will setup a WebEx. Bret From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Matt, Yeah, there might be some inconstancies that we need to address. Perhaps we could setup a call to discuss, with anyone that is interested? Maybe early next week? Thanks Bret From: Matt Pladna <mpladna@lookingglasscyber.com> Bret, I think it makes more sense to stick with endpoints that return STIX bundles so we have one media type for the entire payload.
If we serve a TAXII bundle thatâs a TAXII media type, it will contain STIX objects (which are a different media type); my understanding is the HTTP Content-Type is one type for the entire payload. Also, per the media type definition (https://clicktime.symantec.com/a/1/zUwtlTRepJ1vtepan3ct-OPzSethfi1t85MKpor1y1c=?d=AekN0-15u7XJCOjfMWow13_xZNiCfXbgg7sQULCVh6RAiLL8F01Nk9YTIfwb6KRdN__OsTxPDdCbKkbcry9DpP5JRlyZ_J0Wz9l-8ivHF7SgK8U_PL8NqCGA3M1K4seoXpWltr8OsW0KwqaZBf_ZI6fWs1FfFjhgjKyINXDr9SjtGrOPjvSgIchtK8_uxDGbLOcUSCbvq5oOvfL7zUaDZ-qHHAU8FysOe780uh1VJbbceF8ele1mwAEpz6GAhQ5uwHY0JLBtr47XSM2iILIVVsQzfXkJWsTLR1pkkH6pRjtWWdxLcGCaFzB7U1EjR1O75rflv6LbSUSQh8zvhYDBGKVMYdVCp26Th56QxhzsCKUU0K_nYYwcVh2QcIARzLcKUvEEHm4k3d9krKxAkIcdV4v1rhqXmUj_0JRnMBK1Y9SUXD_WrMDPmW1LuoeQty7WivT3g8BuMqNaTgo%3D&u=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fmedia-types%2Fapplication%2Ftaxii%252Bjson) Note: Despite TAXII searching and returning STIX objects, this
format does not encapsulate any CTI content. It is expected that
CTI documents will be sent with the appropriate mime-type. For
these, consult their own security consideration sections. I take the above to mean we wouldnât encapsulate STIX either, but am I interpreting that incorrectly? Another option I could think of, if the goal is to simplify the media types, is we drop the TAXII content type and make TAXII resources STIX 2 media types instead. The TAXII resources then act as containers/summaries of underlying STIX
data, but Iâm not sure that would make sense. Thoughts? From:
<cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Drew, I like this idea. If we also defined a Bundle in TAXII (not removing the one from STIX), this would get rid of the weird client behaviors where some endpoints need a TAXII media type and some endpoints need a STIX
endpoint. My suggestion would be: 1) Define a Bundle in TAXII 2) Make all endpoints use TAXII media types 3) Add a filter parameter that allows the client to specify which STIX versions it can support. Bret From: drew.varner@ninefx.com <drew.varner@ninefx.com> This is also my understanding. However, we currently donât have the ability for a client to tell the TAXII Server what STIX object versions it understands via accept headers.
I donât think we should use accept headers to tell the server what STIX object versions a client understands. Now that STIX version is an object attribute, I think itâs simply a query parameter on the endpoints.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]