OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]


I would assert that if the TC thinks a binary encoding is desirable, then lets decide that - and ditch JSON and XML, and make a binary encoding (such as protobuf or Thrift or whatever) the standard, and design the standard around said encoding. I believe taking a model and using it to generate a binary encoding is not going to result in an optimal outcome. This even presuming there is even a generator for most of these binary formats, which I do not think there are...

The problems with multiple encoding are more complicated than the use case presented below RE lists. The problems happen when you try to encode complex objects, not simple data structures. Look through the history of the MITRE STIX list to see how many object structure changes Bret and Joep had to make to make a JSON STIX that would make sense to a normal JSON developer.

I will re-iterate - tools are not going to implement multiple formats, because there is no guarantee that the other party would be able to use it. If there is an XML format and a binary format, and the XML format is the only MTI format, then the binary format might as well not exist. Substitute XML and binary for any other two formats in the prior statement, and it holds true.

I will have to do some reading on these examples of XACML and OData as I know nothing about them. Based on a cursory read of XACML on Wikipedia, there are only five active implementations, and only two of them support JSON... I do not see this as a good allegory for CTI where we are looking at thousands of tools using dozens of different implementations of the specification. I would be very curious to know the market penetration statistics of both OData as a whole, and JSON vs ATOM in OData as both are optional. Are they equal? Or does everyone use Atom? Or does everyone use JSON?

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Wunder, John A." ---2015/09/16 10:05:12 AM---Hi Jason/all, Good points from both you and Bernd. I ha"Wunder, John A." ---2015/09/16 10:05:12 AM---Hi Jason/all, Good points from both you and Bernd. I have a few thoughts:

From: "Wunder, John A." <jwunder@mitre.org>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/09/16 10:05 AM
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list [formats discussion]
Sent by: <cti@lists.oasis-open.org>





Hi Jason/all,

Good points from both you and Bernd. I have a few thoughts:

- To your last question, I was personally wondering about whether there were any cases where there was a widely implemented standard with different bindings. I asked Sean (Barnum) about it, and he helpfully pointed me to two OASIS specifications: XACML (which has a JSON profile) and OData. OData in particular does seem to have several bindings on equal footing (notably ATOM and JSON). If anyone else knows of any I think it would be helpful to point us to them so we can see how they approached the binding phase (and the modeling phase, to be honest).

- I share your concern about automatically generating the bindings, but I think the approach would not be to fully automate it but to define a set of rules that you follow to manually or semi-automatically convert it. This is the approach you’ll see in STIX 1.2.1. So, for example, if you have a “list” in the high-level model, in XML you might translate it as <ListItems><ListItem/><ListItem/><ListItem/></ListItems> while in JSON you would use [{item},{item},{item}]. This should allow us to define bindings that correctly follow the design patterns of the binding format (nobody wants XML patterns in JSON or JSON patterns in XML) while still deriving off of the same high-level model and therefore staying semantically compatible. To Bernd’s point #1, while this manual process would be time-consuming, ideally we only need to do it every so often. We could probably also write some ad-hoc scripts to at least semi-automate it, even if we don’t use off-the-shelf support for generating bindings.

- This is my personal opinion, but to me the strongest case to defining an alternate binding is a binary encoding. XML and JSON solve similar use cases but a binary encoding like what Trey has proposed might be a good alternate for high-scale, high-volume use cases where even serializing to JSON is too large or slow. That said, allowing either XML or JSON as an alternative binding (presuming one will be the MTI binding, which may not be the case) shouldn’t have huge ecosystem compatibility implications assuming that the MTI specification is implemented as well (at least on external interfaces).

- I share the concern about creating incompatibilities in the ecosystem, as I’ve expressed before. The intent of the MTI specification is to serve as the lingua franca…while tools could of course choose to only implement an alternative protocol, by having the MTI binding literally be _mandatory_ to claim full compliance with STIX (or CybOX or TAXII) I think we can mitigate those concerns. Users of alternative bindings would either have to support the MTI specification or be very clear that they’re not compatible with it. I believe (and people from OASIS can correct me if I’m wrong) that we can define these rules when we write the conformance sections of the documents.

- To Bernd’s point #3, it’s my opinion that as we simplify and improve the model itself as well as how it’s expressed in the binding format (even if we stick to XML as the MTI spec, we can use simpler XML), the need for things like python-stix should decrease. While we definitely still want to have them, one of the nice thing about a lot of popular formats is that they’re easy enough to use “raw”. When I worked with the Twitter or Facebook APIs (in my previous life at a startup) I didn’t need code-level bindings (what we call APIs) because the JSON and XML formats were easy to work with natively. I think if we get to that point for STIX/CybOX (while not losing support for important use cases of course) we’ll have done a great job. As a side effect, that would also make generation of code-level bindings even easier.

John





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]