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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] Proposal - Simplify Data Model


I will be the first person to say, “Make a choice - either it is in or it is out.” Software Engineering experience is that as we add more and more ‘if’ statements, the likelihood of discovering latent defects (i.e., after you *thought* you killed all the bugs and the code is ready for release) rises non-linearly.

I would also suggest there are ‘optional’ and there are ‘optional’ components. For example, wholesale support for identity management is a big chunk of yes / no. In other words, coarse-grained blocks of stuff is not so bad to have as optional, if the use cases really dictate that some folks will never use the components.

I would also strongly suggest that we adopt (in TAXII) a negotiation mechanism. For examples, see HTTP (the accept and require headers), SMTP (the server listing out everything optional it supports and leaving it up to the client to pick from the list), and SIP (offer / answer, where the client offers capabilities, the server picks what it supports from the list, and the client agrees (or not)). If we have a negotiation mechanism, then people’s code gets a lot less complicated. You know up front what you will and will not do. Anything outside the boundaries then gets gracefully handled.

> On Jul 24, 2015, at 3:04 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:
> 
> Right now I believe there is unnecessary complexity in the data model.  I would like to see things simplified and flattened.  
> 
> The problem we have right now with everything being optional, and given the vast complexity, you can not really write code to do anything with an arbitrary STIX document as the decision tree in code would be insane.  I would like us to seriously look at this and find ways to make it easier.  This work would feed in the conversion from XML to 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
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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