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] Question on Versioning with 2.1


Bret Jordan wrote this message on Fri, Apr 06, 2018 at 20:08 +0000:
> On our editor's call today, John Wunder, Rich Piazza, and myself had a question about how to handle the new spec_version property that the TC decided to add to all objects.
>
>
> Question:
>
> Does changing an object from 2.0 to 2.1 schema result in a version change?  And as such can it only be done by the object creator?
>
>
> The knee jerk reaction I think most people will have will be similar to our initial reaction which was "yes, it requires a version change".  However, upon careful consideration, I am not sure that is a good thing.  Content should be content, regardless of how it is serialized.  Also, without allowing this, there is no good way to upgrade content in the wild.  Products will have to support older versions of STIX for a very very long time.  Further, if you do the derived relationship type, then you need something in TAXII that will say, given this relationship, go find any derived from relationships, and then walk the graph to find all of the new relationships.  This will get ugly really fast and will cause analysts to not see the whole picture.

Yes, it should require a version change..  This is partly why I was
not a fan of this...

The reason it requires a version change is that there may be signifcant
differences between how an object is parsed and understood between
versions...  And allowing non-authors to change versions may result
in bad inteligence being distributed...

Also, if/when we add signing, not signing the version field would be
bad in that you could down grade CTI to hide important fields.. The
downgrade converts fields that can change the meaning, say
a future patterning_language property on an Indicator, into a custom
field, and possibly change the behavior...

This is exactly my argument against adding the draft specifier to the
version field.  We really need to keep data forwards compatible, that
is, if you parse version 2.0 content by a version 2.5 parser, that it
will be semantically the same as being parsed by a 2.0 parser...

> So while I think we initially thought it would be "yes", I think we might now be leaning towards "no".  But this is not a decision that we editors can make.  So we are bringing up to the TC to decide.

Please take into account signatures...  there's a reason why we only
allow authors to change properties, and version should be included.

-- 
John-Mark


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