Re: [cti-stix] Question on Versioning with 2.1

[John-Mark Gurney <jmg@newcontext.com>]

Piazza, Rich wrote this message on Tue, Apr 10, 2018 at 14:41 +0000:
> I agree that allowing someone besides the object creator to upgrade the spec version of an object could be problematic.
> 
> However, there is no guarantee that the object creator will do this, which means that CTI could be lost or "orphaned" in an old spec version.

This is part of the problem of making backwards breaking changes.  If
we kept w/ the original plan of making zero breaking changes, then the
cost of supporting all the old versions of the spec is not a major
problem...

Maybe we need to create a new profile that says which versions of STIX
products support?  So we can have products that are >=2.1, or >=2.0
and the like?

> My thought is that anyone could upgrade the spec version of an object, but only in a restricted way.  In other words, you can only change the spec_version property, and perhaps some other properties, in a prescribed way (described in normative text in the spec).  A special relationship would be used to relate the old spec version object to the new spec version object (“upgrade_spec_version”).
> 
> Anyone can make this upgrade, but the new object should be identical (except for the new ID) regardless of who does it.  This might help with the signature issue, but I have to think about that more…

Well, if you're creating a new object w/ new UUID, then there isn't a
problem, as it's not the same object.  I do agree that linking the
new object to the old object is a good idea when this happens though.

If you're trying to allow an upgrade of the object w/ the same UUID,
then you have to do something like have original_spec_version, and
make sure that future products warn the users about this, etc, which
becomes problematic.

> On 4/9/18, 7:53 PM, "cti-stix@lists.oasis-open.org on behalf of John-Mark Gurney" <cti-stix@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote:
> 
> 
> 
>     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
> 
> 
> 
>     ---------------------------------------------------------------------
> 
>     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
> 
> 
> 
> 
> 
> 

-- 
John-Mark