Re: [cti-stix] Proposal - Single Binding

5) be consistent across all of the CTI specs

6) be reasonably light weight on the network

7) be memory and cpu friendly

8) be easy to understand

I really like Cap-n-Proto, I think it is really neat.. But I worry about the cost of entry for web developers and app developers. I can see hundreds or thousands of apps being created over the next 5 years, if we are successful. I can see PHP and AJAX based STIX/CybOX systems talking to a TAXII server. I can see handhelds emitting and enriching CTI data. I can see super interning UIs being created to do things with CTI data.

Basically, I want the cost of entry and the barrier of entry to be so small that vendors and developers want to use our standards. And they say, "why would you use anything else, this is so EASY". This is why I suggest we do JSON. The developer community loves it and is very comfortable with it. And like John said, later on, if warranted, we can do Cap-n-Proto for those certain groups that need higher throughput. But if we get to that point, that is a GOOD problem to have.

As I have said many times over, and I think MITRE folks have heard this too.... A lot of groups have said they would use STIX, CybOX, MAEC if it was NOT in XML. Developers I talk to outside of my company always respond with the same thing, "can I have something other than XML".

Lets solve this, lets make it so easy for people to get up and going. Lets build short video web casts on this to get people up to speed faster. Lets WIN.

Thanks,

Bret

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jul 30, 2015, at 06:46, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

To introduce a wild idea.. instead of having the artifact of the standard be a protocol and reference implementation, the artifact could simply be an Apache Avro schema...

The standard would then not be tied to any binding or implementation at all. And, no one would ever have to write code to "speak STIX", they would simply take the reference Avro schema and generate the code for whatever protocols they wanted to support.

The big downside is "TAXII hub" products would probably need to run support for many protocols simultaneously since some of their clients maybe speaking Protobuf and some JSON

I don't know really what I think of this idea but thought i should put it out there.

-
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

<graycol.gif>Trey Darley ---2015/07/30 09:24:52 AM---Hey, guys - Cap'n Proto is supported by C++, Erlang, _javascript_, Python, Rust, C, C#, Go, Java, Lua,

From: Trey Darley <trey@soltra.com>
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, Terry MacDonald <terry.macdonald@threatloop.com>
Cc: Eric Burger <Eric.Burger@georgetown.edu>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/07/30 09:24 AM
Subject: Re: [cti-stix] Proposal - Single Binding
Sent by: <cti-stix@lists.oasis-open.org>

Hey, guys -

Cap'n Proto is supported by C++, Erlang, _javascript_, Python, Rust, C, C#, Go, Java, Lua, OCaml, and Ruby [0]. I think that pretty well covers the landscape, unless someone out there is working in Haskell or Lisp?!

The biggest advantages I see with Cap'n Proto have nothing to do with performance.

0) The ability to evolve a spec without breaking backwards-compatibility [1].
1) The fact that you get input validation and parsing for free [2].

[0]: https://capnproto.org/otherlang.html
[1]: https://capnproto.org/language.html#evolving-your-protocol
[2]: https://capnproto.org/index.html

Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, July 30, 2015 13:56
To: Jordan, Bret; Terry MacDonald
Cc: Eric Burger; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal - Single Binding

I agree with Bret: one binding to rule them all, one binding to…bind…them.

I also agree that the single binding should be JSON. I think people will have huge problems implementing a binary protocol across a variety of languages and platforms. We would have to consider language/library support, compatibility between different libraries, and all the other challenges of a binary protocol.

If at some point volume surpasses what we can do in JSON that would be a good time to counter my first statement and add a binary protocol *for only those use cases* and continue to use JSON for other use cases. In other words, we might add another binding but each use case would only have a single supported binding.

John

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Thursday, July 30, 2015 at 2:36 AM
To: Terry MacDonald
Cc: Eric Burger, "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Single Binding

I am not against a binary version. I do have concerns about ease of use with binary. I also have concerns with good solid support for handhelds.

But that discussion aside, I think we both agree on "not XML" and "only one way to do it".

Bret

Sent from my Commodore 64

On Jul 29, 2015, at 11:03 PM, Terry MacDonald <terry.macdonald@threatloop.com> wrote:
I disagree with Brett's statement that the only binding should be JSON. I believe that the only binding should be a binary protocol of some sort. We differ in our beliefs there, but we do both believe there should only be a single binding. One way to do it.
The protocol discussion and testing stages should be very interesting when we go through the various options as a community.
Cheers
Terry MacDonald
> On 30 Jul 2015 1:38 pm, "Eric Burger" <Eric.Burger@georgetown.edu> wrote:
>>
>> Fine with me. Anyone else?
>>
>> The counter argument might be “Why bother with UML?” I would offer it is because UML and OWL will let us see the actual relationships. What may be cool is to compile them into JSON bindings. That’s a <hint> research project.
>>
>> > On Jul 24, 2015, at 3:00 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:
>> >
>> > On the community call there was a statement made that STIX will continue down the old path of UML and then OWL with bindings for XML and others. There needs to be a single binding, and it should be JSON. The only reason I wanted UML was to break our dependency on XML-isims to make it easier to do JSON.
>> >
>> > Bret
>> >
>> > Sent from my Commodore 64
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this mail list, you must leave the OASIS TC that
>> > generates this mail. Follow this link to all your TCs in OASIS at:
>> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> >
>>

cti-stix message