Re: version proposed change to STIX 2.0 RC3

["Bret Jordan (CS)" <Bret_Jordan@symantec.com>]

I agree with this proposal as well.  Though, I will admit at first glance I was mentally wanting to hold on to the "version" field.  But then I started to ask myself as to why?  Why do we need two fields that are really just the same thing?  They are both "numbers" under the covers.  They both increment when you make a change. 

I think when we started versioning and some of the other concepts, we were still thinking of STIX as a human generated, parsed, and read language.  But I think we are now well beyond that.  We are realizing that humans will probably never read the content over the wire (other than for debugging). They will read STIX from a UI, and that UI can display the content how ever the humans need it.

So I support this change as I do not see any valid reason for keeping both fields.  

Bret

---

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Thursday, December 1, 2016 7:56:04 AM
To: cti@lists.oasis-open.org
Subject: [cti] version proposed change to STIX 2.0 RC3

 

All –

 

As agreed on the last working call I was asked to send the proposed text changes for the version number proposal. See the attached deck for intro.

 

Proposal:               Remove version number and rely on created/modified timestamps to provide the versioning information.

Rationale:             Implementers more easily can generate versioning.

  

I made changes to Part 1 and Part 2 (not attached). If anyone wants to see Part 2 changes (primarily changes to STIX objects property tables to be consistent with change to version property) let me know and I can send the doc.

 

Allan